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Executive Summary 

The NASA/SP-2015-3709, Human Systems Integration (HSI) Practitioner’s Guide, also known 
as the “HSIPG,” provides a tool for implementing HSI activities within the NASA systems 
engineering framework. The HSIPG is written to aid the HSI practitioner engaged in a program 
or project (P/P), and serves as a knowledge base to allow the practitioner to step into an HSI lead 
or team member role for NASA missions. Additionally, this HSIPG is written to address the role 
of HSI in the P/P management and systems engineering communities and aid their understanding 
of the value added by incorporating good HSI practices into their programs and projects. 

Through helping to build a community of knowledgeable HSI practitioners, this document also 
hopes to build advocacy across the Agency for establishing strong, consistent HSI policies and 
practices. 

Human Systems Integration (HSI) has been successfully adopted (and adapted) by several 
federal agencies — most notably the U.S. Department of Defense (DoD) and the Nuclear 
Regulatory Commission (NRC) — as a methodology for reducing system life cycle costs 
(LCCs). These cost savings manifest themselves due to reductions in required numbers of 
personnel, the practice of human-centered design, decreased reliance on specialized skills for 
operations, shortened training time, efficient logistics and maintenance, and fewer safety-related 
risks and mishaps due to unintended human/system interactions. The HSI process for NASA 
establishes how cost savings and mission success can be realized through systems engineering. 

Every program or project has unique attributes. This HSIPG is not intended to provide one-size - 
fits-all recommendations for HSI implementation. Rather, HSI processes should be tailored to 
the size, scope, and goals of individual situations. The instructions and processes identified here 
are best used as a starting point for implementing human-centered system concepts and designs 
across programs and projects of varying types, including manned and unmanned, human 
spaceflight, aviation, robotics, and environmental science missions. The practitioner using this 
guide should have expertise in Systems Engineering or other disciplines involved in producing 
systems with anticipated human interactions. (See section 1.6 of this guide for further discussion 
on HSI discipline domains.) 

The HSIPG provides an “HSI layer” to the NASA Systems Engineering Engine (SEE), detailed 
in NASA Procedural Requirement (NPR) 7123. IB, NASA Systems Engineering Processes and 
Requirements, and further explained in NASA/SP-2007-6105, Systems Engineering Handbook 
(see HSIPG Table 2.2-1, NASA Documents with HSI Content, for specific references and 
document versions). 
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1 .0 INTRODUCTION TO NASA HUMAN SYSTEMS INTEGRATION 

NASA systems are designed to fulfill mission goals and scientific objectives by addressing 
various stakeholder needs and constraints. HSI is a system engineering discipline that applies 
knowledge of human capabilities and limitations throughout the design, implementation, and 
operation of hardware and software. The Human in HSI refers to all personnel involved with a 
given system, including users, operators, maintainers, assemblers, ground support personnel, 
logistics suppliers, personnel trainers. HSI embraces the concept of The Human as a sub-system 
on par with the hardware and software sub-systems. 

The HSI discipline includes a range of managerial and technical domains and specialties — e.g., 
systems engineers, program managers, NASA institutional support offices, human factors 
engineers, safety and reliability analysts, psychologists, medical professionals, logistics and 
maintenance expertise. HSI domains collectively define (a) how human capabilities or 
limitations impact the hardware and software of any given system, in terms of its design, 
effectiveness, operation, support and the associated cost and affordability of these components, 
and (b) how the system hardware, software, and environment impact human performance. Total 
system performance is a measurable outcome of the effectiveness of the integrated interaction of 
hardware, software, and human elements. Essential engineering expertise areas change as the 
systems engineering (SE) lifecycle progresses. For this reason, these roles and responsibilities 
must be identified within the Human Systems Integration Plan at the outset of a project, either as 
a standalone document or as a part of a program’s or project’s (P/P’s) System Engineering 
Management Plan (SEMP). 

1.1 Guide Purpose 

The purpose of the NASA/SP-2015-3709, Human Systems Integration (HSI) Practitioner’s 
Guide, also known as the HSIPG, is to enable incorporation of Agency HSI policies and 
processes into development and deployment of NASA systems. The HSIPG is intended to serve 
as a training and support aid for NASA HSI practitioners and their team members. The HSIPG 
is written to aid the HSI practitioner engaged in a P/P, and serves as a knowledge base to allow 
the practitioner to step into an HSI lead or team member role for NASA missions. Additionally, 
this guide should be shared with others in the P/P management and SE communities as an aide to 
their understanding the value added by incorporating good HSI practices into their endeavors. 

Specific aims of this guide are to define HSI, to illustrate the value of HSI in programmatic 
decisions, to demonstrate how HSI fits into the NASA SE process, to provide examples of HSI 
contributions to reductions in human error and life cycle cost (LCC), and to provide helpful 
information on HSI resources within the NASA community. 

The Human Systems Integration Plan (HSIP) is a recommended deliverable defined in NASA 
Procedural Requirement (NPR) 7 123. IB, NASA Systems Engineering Processes and 
Requirements, Appendix G: Life-cycle and Technical Review Entrance and Success Criteria, and 
in the supporting Systems Engineering Handbook (SEHB) (see HSIPG Table 2.2-1, NASA 
Documents with HSI Content, for specific references and document versions). This guide 
supports creating the HSI Plan. 
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Every P/P has unique attributes. This guide is not intended to provide one-size-fits-all 
recommendations for HSI implementation. Rather, HSI processes should be tailored to the size, 
scope, and goals of individual situations. The instructions and processes identified here are best 
used as a starting point for implementing human-centered system concepts and designs across 
programs and projects of varying types, including manned and unmanned, human spaceflight, 
aviation, robotics, and environmental science missions. The practitioner using this guide should 
have expertise in SE or other disciplines involved in producing systems with anticipated human 
interactions. (See section 1.6 of this guide for further discussion on HSI discipline domains.) 

Since HSI is an emerging requirement in NASA programmatic and management policies and 
practices, it is recommended that this guide be reviewed and updated when appropriate to 
capture evolving developments in the pathway towards a recognized, documented NASA 
approach to HSI. 

1.2 How to Use this Guide 

This guide is written to support multiple use scenarios, as shown below, following Table 1.2-1, 
Chapter Purpose. The guidance in the use case scenarios are not meant to be prescriptive or 
restrictive, but to provide a mechanism to categorize a reader’s background and provide the right 
HSI material to support an aspiring practitioner. 

Chapter 3 provides the “step-by-step” guidance for each phase of the SE life cycle. The tables in 
each section of Chapter 3 are a streamlined representation of the complex, recursive, iterative, 
and tailorable Systems Engineering Engine (SEE) processes. The reader is advised to acquire a 
solid grasp of the SEE processes, by study or through training, in order to be able to successfully 
apply HSI. 


Table 1 .2-1 Chapter Purpose 


Chapter 

Short Title 

Purpose 

1 

Introduction to HSI 

“Why HSI” 

• Background and History 

• Key Concepts 

• HSI Domains 

2 

Implementing HSI 

“Who” 

• Authority hierarchy 

• NASA HSI Documents 

• Collaboration 

3 

HSI in NASA SEE 

“When” and “What” 

• A Phase-by-Phase HSI Overlay to NASA 
SEE 

• Product maturity by Phase 

4 

Planning and Execution 

“How” 

• Getting Organized 

• Tailoring for Program/Project Size 

• Planning for HSI 

• Key Skills for the HSI Practitioner 
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Chapter 

Short Title 

Purpose 

App. A 

HSI Plan Outline 

Annotated HSI Plan outline to aid HSI 
practitioner development of HSI Plan 

App. B 

HSI Planning Checklist 

Sample of checklist to aid practitioner in 
assessing scope of HSI effort during early 
lifecycle phases 

App. C 

HSI Implementation 
Experiences 

HSI implementation examples with 
positive/negative lessons learned and HSI 
ideal state 

App. D 

References 

List of HSI information from NASA, Industry, 
DoD, and other sources 


1.2.1 HSIPG Use Cases 

General: Regardless of background, all readers should understand the four Key Concepts of 
HSI in section 1.4, the HSI process approach in section 1.5, and be familiar with the HSI 
Domains in section 1.6. Also, review the annotated HSI Plan Outline in Appendix A. If 
supporting an existing Program or Project, review the SEMP and/or HSI Plan, if they exist. 

Use Case 1: 1 already know the fundamentals of the SEE in the SEHB, but where do I get HSI- 
specific Skills and Guidance? 

Answer: Start with HSIPG sections 4.5 and 4.6 for picking up “how-to” and key practices. Then 
use HSIPG Chapter 3 to provide the “HSI layer” to the NASA life cycle phases and SEE. For 
domain-specific knowledge (e.g., Human Factors Engineering [HFE]), utilize the NASA 
Engineering Network (NEN) site for best practices and resources. Many HFE resources are also 
listed in HSIPG Chapter 5. 

Use Case 2: 1 already know HFE, so how do I expand my knowledge to include HSI and the 
SEE? 

Answer: Start with HSIPG Chapter 3 to learn more about the NASA SEE. For further study, 
refer to fundamentals and life cycle sections of the SEHB. Then read HSIPG Chapter 4. 

Use Case 3: 1 was just assigned as an HSI practitioner for a project. Where do I start? 

Answer: It is recommended that HSI Practitioners read the entire guide. A person who is the 
designated HSI practitioner should be well informed with the entire content of the HSIPG and 
the resources that are referenced. Having said that, sometimes a practioner will have to “jump 
in” to an already up and running project. If that is the case, then it is recommended to start with 
the current life cycle phase discussion in the appropriate section of Chapter 3, for near-term 
activities. And then refer to section 4.4, which describes details on most activities a practitioner 
will help conduct for the P/P, such as building a team and writing an HSI plan. Eventually, a gap 
analysis may need to be performed to assess if any activities/products were “skipped over” and 
need to be performed/developed. 


1-3 


HSI Practitioner's Guide 


HSIPG section 4.2 on tailoring to P/P size will be of particular interest, which will also lead you 
to the HSI Implementation Planning Checklist in HSIPG Appendix B. From there you can begin 
to organize the HSI team, budget, and expectations. 

Use Case 4: 1 am a project manager and I need to be in compliance with NPR 7123.1B, which 
now includes performing HSI. I do not have much time, so what do I really need to know? 

Answer: Review HSIPG Chapters 1-3 plus section 4.2. And then find yourself an HSI 
Practitioner. 

1.3 History of HSI 

Systems have become increasingly complex, often due to the enormous capabilities and 
advances of micro-circuitry and digital firmware/software. Early and careful consideration of 
the capabilities and limitations of human performance and behavior when interacting with such 
complexity has become essential to planning and designing for total system outcome and 
performance. Hardware and software systems enable humans to perform advanced mission tasks 
and objectives in extreme and potentially lethal environments. Systems can be designed that to 
require high levels of human specialization and training or that to accommodate a broad 
population of human capabilities. The goal of HSI is to ensure that the human/system integration 
is carefully considered and planned from the outset of any program or project. 

The DoD was the first U.S. government agency to identify the need for better design processes 
for early and thorough consideration of the human element in systems design since they were 
facing rapid ubiquitous rates of escalation in life cycle system costs due to unanticipated 
personnel training costs, user interface re-designs, logistics and maintenance expenses, system 
down time, and repair costs necessary to keep systems operational. Since most cost escalations 
were due to personnel time and expenditures, it became clear that better design practices for 
inclusion of the human elements required to develop, deploy, and operate a system needed to 
become standard in life cycle SE and P/P management. Synergistic interaction between a system 
and its human elements is key to attaining expected total system performance outcomes and to 
minimizing total ownership costs. Therefore, to realize the full and intended potential that 
complex systems offer, the DoD in 2003 mandated that a “total system approach” must apply 
HSI to all developments “to optimize total system performance (hardware, software, and 
human), operational effectiveness, and suitability, survivability, safety, and affordability” [DoD 
Directive 5000.01, The Defense Acquisition System, Enclosure (requirement 1.29)]. 
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Development activities must apply rigorous application of systemic approaches to HSI to ensure 
the total impact of human capabilities and limitations throughout a system’s life cycle are 
addressed in every aspect of system acquisition. The current DoD Instruction 5000.02, 

Operation of the Defense Acquisition System, Enclosure 7 (section 2), states that: 

[The goal of HSI is] “to optimize total system performance and total ownership costs, 
while ensuring that the system is designed, operated, and maintained to effectively 
provide the user with the ability to complete their mission.” 

In practice, this means that the human element in acquisition programs is given equal importance 
to hardware and software. 

NASA has a history of considering human health and performance in spacecraft and mission 
design, particularly in human space flight mission planning and design. Human space flight 
research has been conducted since the early 1960s with incremental advancements in human- 
rated missions and simulators. In the 1970s and 1980s, NASA advanced aviation safety and 
matured concepts in crew resource management. The 1990s to present day have witnessed 
NASA advancements in research and automation, system monitoring, information presentation, 
and information sharing between systems and humans. With NASA’s vision of exploration 
beyond low-Earth orbit, advanced systems are needed that support extended human habitation 
and autonomy. Such challenges present new opportunities to deploy and employ HSI practices. 

NASA, unlike the DoD, did not have a formal acquisition mandate to include HSI activities in 
programs and projects, or to include HSI deliverables in the procurement process until 2013 (see 
below). However, NASA does have a rich heritage of concern for and protection of their space 
flight crews, and as a result has considered human health and performance in spacecraft and 
mission design for many years. In addition, in 2012 NASA updated NPR 8705. 2B, Human- 
Rating Requirements for Space Systems (w/change 4 dated 8/21/2012), a procedural 
requirements document intended to ensure the protection and safety of crewmembers and 
passengers on NASA space missions. The Human-Rating Requirements define and implement 
processes, procedures, and requirements necessary to produce human-rated space systems, and 
define a human-rating certification path for the Program Managers (PMs) and their teams to 
follow in conjunction with select traditional program management milestones. 

In 2015, an updated version of NASA-STD-3001, NASA Space Flight Human-System Standard, 
Volume 2: Human Factors, Habitability, and Environmental Health, was released that included a 
new requirement for Human-Centered Design: 

3.5 Human-Centered Design Process [V2 3005] 

Each human space flight program shall establish and execute a human-centered design 
process that includes the following at a minimum: 

a. Concepts of operation and scenario developmen t 

b. Task analyses 

c. Function allocation between humans and systems 

d. Allocation of roles and responsibilities among humans 
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e. Iterative conceptual design and prototyping 

f. Empirical testing , e.g., human-in-the-loop, testing with representative population, or 
model-based assessment of human-system performance 

g. In-situ monitoring of human-system performance during flight. 

Rationale: Human-centered design is a performance -based approach that focuses on 
making a design usable by the human throughout the system ’s life cycle. (See ISO 
13407, Human-centered design processes for interactive systems). It is characterized 
by early and frequent user involvement, performance assessment, and an iterative 
design-test-redesign process. 

A typical human-centered design process is negotiated during the implementation 
process and documented in a human factors engineering control plan, where each of the 
above process steps results in at least one documented deliverable. Effective human- 
centered design starts with a clear definition of human activities, which flows down from 
the concept of operations and anticipated scenarios, to more specific analyses of tasks 
and to even more specific questions of allocation of roles and responsibilities between the 
human and systems (where the term “systems” refers to machines or automated systems). 
Iterative design is a key component of this process, by which concepts are continually 
refined. Next, more rigorous evaluation of designs is required, by computational human 
modeling, empirical methods, or a blend of the two. Empirical methods include 
laboratory studies and human-in-the-loop simulation testing. Finally, real-time 
measurements of system performance are needed during flight to generate lessons 
learned. More information about methods and techniques can be found in chapter 3, 

General, of the HIDH. 

Inclusion of this requirement for all human space flight programs was a significant step forward 
in capturing and documenting a NASA approach to HSI. Note, however, that this only currently 
applies to human space flight programs, but not to other NASA programs such as aviation and 
unmanned space exploration. Nonetheless, a human-centered design (HCD) approach to system 
acquisition and development is a critical concept in HSI. More information on methods and 
techniques in HCD can be found in NASA/SP-2010-3407R1, Human Integration Design 
Handbook (HIDH), Chapter 3, General, a companion document to NASA-STD-3001. 

In 2012, two groups of NASA personnel interested in HSI were formed to spread and promote 
information on the topic and to work toward a NASA-specific implementation of HSI. A multi- 
Center HSI Steering Committee was chartered under the auspices of the Office of the Chief 
Engineer (OCE). The charter for the OCE HSI Steering Committee includes signature 
membership of 10 NASA Centers. At the Johnson Space Center (JSC), an HSI Employee 
Resource Group (ERG) was formed to socialize, inform, and promote HSI across JSC technical 
directorates. Members of the HSI ERG worked with JSC’s Systems Engineering Forum to form 
an HSI Splinter to the Forum to initiate efforts to change NASA’s SE documentation to be more 
inclusive of HSI and the human element. 
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In 2013, NPR 7 123. IB was updated to Revision B, in which a definition of HSI was for the first 
time formally captured in NASA documentation: 

Human Systems Integration: An interdisciplinary and comprehensive management and 
technical process that focuses on the integration of human considerations into the system 
acquisition and development processes to enhance human system design, reduce life- 
cycle ownership cost, and optimize total system performance. Human system domain 
design activities associated with manpower, personnel, train ing, human factors 
engineering, safety, health, habitability, and survivability are considered concurrently 
and integrated with all other systems engineering design activities. 

NPR 7123. IB also includes a guideline that all NASA programs and projects generate an HSI 
Plan that captures the implementation of HSI on the P/P. Appendix G of the NPR provides 
recommended milestones during the P/P life cycle at which the HSI Plan is updated with new 
information as the P/P matures. 

In 2014 NASA released NASA/TP-2014-218556, Human Integration Design Processes (HIDP), 
which captures NASA human engineering and HSI lessons learned that are not adequately 
addressed by standards and requirements alone — i.e., they are complex, iterative processes such 
as determining the appropriate net habitable volume of a human space flight spacecraft for a 
given crew size, mission scope, and mission duration. As of 2015, NASA/SP-2007-6105 — a 
companion to NPR 7 123. IB — is being revised. The update will include significant new 
information on HSI and on integrating the human element into NASA SE processes. See HSIPG 
Table 2.2-1, NASA Documents with HSI Content, for specific references and document versions 
of the SEHB. 

1.4 Key Concepts of HSI 

Four key concepts define an effective HSI effort. 

1) The system comprises hardware, software, and human elements needed to operate and 
maintain the system within an environment. As demonstrated in several HSI case 
studies in Appendix C, the human element is critical to the overall performance, 
effectiveness, and efficiency of the total system. The initial paragraph of NPR 7 123. IB 
states that, “This systems [engineering] approach is applied to all elements of a system 
(i.e., hardware, software, human system integration [sic]) and all hierarchical levels of a 
system over the complete project life cycle.” [Editor’s note: typo; “system integration” 
should not appear in this quote.] 

2) Human interactions that need to be considered in P/P management, SE, and HSI include 
all personnel that interface with a system in the expected environment and at any and all 
phases of the system’s life cycle — i.e., the end users (pilots, crewmembers), maintainers, 
ground controllers, logistics personnel, sustaining engineers, etc. 

3) Successful HSI depends upon integration and collaboration of multiple domains . Prior 
to the concept of HSI, separate human-centered domains had to interact with the P/P 
management structures as independent disciplines due to the lack of a coordinated 
approach to including the human element in system design and engineering. Proper 
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implementation of HSI helps all human-centered domains have a more assured, 
coordinated voice in system design and engineering. In addition, having HSI 
coordinators helps the P/P managers since it is expected that the HSI team lead will 
resolve or mitigate conflicting inputs among human systems subject matter experts 
before the P/P management needs to engage. Via internal integration, HSI domain 
interests can better participate in P/P trade studies and design collaboration. 

4) HSI must be considered and established in P/P planning early in system development 
and acquisition — i.e., in the early concept and design phases of NASA SE — and applied 
iteratively throughout the development life cycle from pre-Phase A through to Phase F 
(refer to Figure 1.4-1, NASA Fife Cycle Phases). Early application of HSI provides the 
best opportunity to maximize FCC efficiency and total system performance. HSI 
requirements and goals must be developed in phase with system capability-based 
requirements. HSI requirements will drive HSI metrics and embed HSI goals within the 
system design. After a system is designed, implementation of HSI oversight or 
workarounds due to the lack of HSI during design can be very expensive. 
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Expanding on this last point, as noted earlier, the DoD made HSI mandatory when faced with 
alarming, unanticipated cost escalation in deploying new weapon systems. Much of the 
unexpected cost growth was due to personnel costs in systems’ operations phase — i.e., it took 
more people and more advanced skills to operate, maintain, and logistically support systems than 
was planned. Faced with the awareness of cost growth in the human elements needed to make 
and keep systems operational, HSI was seen as a methodology to focus on systems’ full LCCs — 
conception through operations — starting at the outset of new programs and projects. Figure 1.4- 
2, based on a figure from the INCOSE Systems Engineering Handbook (2007), shows that LCC 
of a program or project are “locked in” early in programs or projects. 

Although this early pre- determination of systems’ LCC may apply to any element of systems’ 
design whose consideration is neglected in the early P/P, it is particularly noteworthy for HSI, 
since hardware and software system designers quite often focus on technology development to 
the detriment of considering the human elements of a system. A discussion of the LCC effects of 
HSI is contained in section 4.4.9 of this HSIPG . 
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1.5 The NASA HSI Process Approach 

Ideally, NASA programs and projects treat HSI as an integral part of the standard SE process 
such that when the SEE “runs” — i.e., during execution of the SE process — HSI work is 
performed. In this document, you will encounter a tight synchronization between HSI process 
and the NASA SEE processes. The steps to execute HSI processes are in lock-step with the 
NASA SEE processes. The NASA P/P Life Cycle from an HSI perspective is provided in 
Chapter 3 of this guide. 

The NASA approach of identifying HSI as a cross-cutting process provides HSI structure to the 
SEE, while still allowing for tailoring of HSI to the mission of a P/P. The first benefit of this 
approach is that a system engineer can readily leam to be an HSI practitioner . Similarly, by 
performing HSI, human-centered design practitioners learn SE best practices and facilitate 
execution of SEE processes. 

The second benefit of this approach is directly to the P/P stakeholders-i.e., to ensure that the 
original operational vision is fulfilled . The HSI practitioner can provide ongoing P/P objectivity 
through continually insisting on validation of questions such as, “Are we building the system 
originally envisioned?” or “Does this system design solve the stakeholders’ challenge and fulfill 
the stakeholders’ needs?” 

The third benefit is the immediate applicability of HSI practices to SE workflow. By integrating 
HSI with the SEE, HSI becomes another best practice for systems engineers rather than 
something that “somebody else” performs. 

1.6 HSI Domains 

HSI incorporates functional areas, referred to as domains. . NASA HSI domains are listed in 
Table 1.6-1. HSI personnel with integrated domain oversight implement HSI processes and 
practices and integrate HSI domain involvement throughout the NASA SE life cycle. Overall 
HSI domain integration oversight is essential to effective HSI implementation. While there may 
be overlap among those responsible for overall HSI domain integration and specific domain 
expertise, the parties responsible for providing consolidated HSI input rely on discipline experts 
in the HSI domains — i.e., they do not replace them. Functional implementation of HSI is based 
on regular and frequent communication, coordination, and integration across the HSI domains 
providing human-systems expertise. 

As Figure 1.6-1 illustrates, each HSI domain has the potential to affect and interact with the other 
domains, making it critical to execute an integrated discipline approach. Human Factors 
Engineering (HFE) is the central domain in that it is responsible for characterizing human 
capabilities and constraints and for applying knowledge of these to engineered 
hardware/software engineering systems’ design. Because of their direct interaction with 
systems’ design, recommendations by HFE discipline experts can have a strong influence on 
mission success and operations costs, working collaboratively with the principles, goals, and 
metrics of all the other domains. 
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Table 1.6-1 NASA HSI Domains 


Domain 

Definition 

Examples of Expertise 

Human Factors 

Engineering 

(HFE) 

Designing hardware and software to optimize 
human well-being and overall system safety, 
performance, and operability by designing with 
an emphasis on human capabilities and 
limitations as they impact and are impacted by 
system design across mission environments and 
conditions (nominal, contingency, and 
emergency) to support robust integration of all 
humans interacting with a system throughout its 
life cycle. HFE solutions are guided by three 
principles: system demands shall be compatible 
with human capabilities and limitations; systems 
shall enable the utilization of human capabilities 
in non-routine and unpredicted situations; and 
systems shall tolerate and recover from human 
errors. 

Task analysis, human 
performance measures 
(workload, usability, situation 
awareness), HFE Design 
(anthropometry and 
biomechanics, crew functions, 
habitat architecture), HITL 
Evaluation, Human Error 
Analysis, Human-system 
Interface, Systems Design, 
and HFE Analysis 

Operations 

Resources 

The considerations and resources required for 
operations planning and execution. This 
includes operability and human effectiveness for 
flight and ground crews to drive system design 
and development phases, as well as trades for 
function allocation, automation, and autonomy. 

Operations process design for 
both ground and flight crew, 
human/machine resource 
allocation, Mission 
Operations, Resource 
modeling and complexity 
analysis, Flight Operations, 
procedure development, crew 
time, staffing/qualifications 
analysis 

Maintainability 

and 

Supportability 

Design to simplify maintenance and optimize 
human resources, spares, consumables, and 
logistics, which are essential due to limited time, 
access, and distance for space missions. 

In-flight Maintenance and 
Housekeeping, Ground 
Maintenance and Assembly, 
Sustainability and Logistics 

Habitability and 
Environment 

External and internal environment 
considerations for human habitat and exposure 
to natural environment including factors of living 
and working conditions necessary to sustain the 
morale, safety, health, and performance of the 
user population which directly affect personnel 
effectiveness. 

Environmental Health, 
Radiation Health, Toxicology, 
Nutrition, Acoustics, 
Architecture Crew Health and 
Countermeasures, EVA 
Physiology, Medical 
Concerns, Lighting 

Safety 

Safety factors ensure the execution of mission 
activities with minimal risk to personnel. Mission 
success includes returning the crew following 
completion of mission objectives and 
maintaining the safety of ground personnel. 

Safety analysis, Reliability, 
Quality Assurance, factors of 
survivability, human rating 
analysis, hazard analysis 

Training 

Design training program to simplify the 
resources that are required to provide personnel 
with requisite knowledge, skills, and abilities to 
properly operate, maintain, and support the 
system. 

Instructional Design, Training 
Facility Development, On- 
board Training (OBT) 
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Though not shown in Figure 1.6-1, survivability is part of the HFE, Safety, and Habitability and 
Environment domain analysis. 
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Figure 1.6-1 HSI Domain Interaction 


Note that the AFD-090121-054, Air Force Human Systems Integration Handbook: Planning and 
Execution of Human Systems Integration (2008), identifies the following nine domains: 
Manpower, Personnel, Training, HFE, Environment, Safety, Occupational Health, Survivability, 
and Habitability. The long-established DoD HSI domain categories were assessed and 
customized by the NASA OCE HSI Steering Committee to establish the set of domains for 
NASA HSI implementation. The NASA HSI domains are less focused on the large work force 
and diverse skill sets required for DoD mission objectives and more focused on habitability, 
system safety, reliability, and usability concerns. HFE is a significant domain for both DoD and 
NASA HSI processes. 

1.7 Distinguishing HSI, HCD, and HFE as Systems Engineering Elements 

The terms HSI, HCD, and HFE are all used in concert within this document. HSI is defined by 
NASA in NPR 7 123. IB and is further described with its technical domains in Table 1.6-1 and in 
the early sections of this guide. 

HFE is defined in Table 1.6-1 as one of the HSI domains. 
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HCD is defined as an approach to interactive system development that focuses on making 
systems usable by ensuring that the needs, abilities, and limitations of the human user are met. 
HCD is a multi-disciplinary activity that involves a range of skills and stakeholders that 
collaborate on design. Most importantly, HCD is applied through an iterative approach that uses 
data gathered from frequent evaluations with users to inform system design. (Refer to 
NASA/TP-2014-218556.) 

In summary, as an inherent part of the NASA SE process, HSI applies and integrates multiple 
domains including HFE, and it employs the HCD approach for system design. 
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2.0 IMPLEMENTING HUMAN SYSTEMS INTEGRATION 

2.1 NASA-HSI Authority 

Within the organization of NASA, there are programmatic authorities (mission directorates) and 

institutional authorities (cross-cutting technical offices). Control boards are the method for 
institutional and programmatic authorities to reach agreements on specific P/P issues. 

2.1.1 Programmatic Authorities 

NASA mission directorates provide programmatic authority and they create P/P to carry out their 
initiatives. These P/P fund NASA Center institutional organizations (e.g., Engineering, Safety 
and Mission Assurance [S&MA], Human Health and Performance [HH&P], Mission Operations) 
to staff the P/P technical offices and teams. These P/P-funded technical personnel include 
program managers, systems engineers, and infrastructures that often derive from Center 
institutional resources but that may become P/P direct hires and resources. These P/P personnel 
execute the implementation of Agency P/P directives such as NPR 7120.5E, NASA Space Flight 
Program and Project Management Requirements w/Changes 1-13. Typically, P/P funds are also 
deployed to engage subject matter experts (SMEs) in the specific areas necessary to execute the 
P/P. Thus, program HSI work is arranged and managed by P/P-funded personnel (NASA civil 
servants and often the program’s prime contractor), in coordination with the cognizant NASA 
Institutional Technical Authorities. P/P-funded SME personnel are the primary resources by 
which HSI work is accomplished to execute the necessary HSI processes and products for the 
program or project. The involvement of NASA SMEs generates technical insight into the P/P 
needed by the Technical Authorities (TAs) to monitor progress. 

2.1.2 Institutional Authorities 

NASA institutions typically provide the s ki lls (personnel) and resources (facilities, labs, etc.) to 
execute HSI when funded to do so by a particular program or project. Additionally, NASA 
institutions have a responsibility to provide necessary functions that are separate from those of 
programmatic authorities. Related to implementation of HSI, one of their key functions is that of 
technical authority. The three NASA TAs are: 

1) The Engineering Technical Authority (ETA) is a function of the Agency’s OCE. ETA is 
delegated from the Agency’s Chief Engineer to Center Directors and further delegated 
within the centers. Refer to NPR 7120.5E for details of the ETA. The principal ETA 
documents currently supporting HSI are NPR 7 123. IB and the accompanying SEHB 
(see document references in table 2.2-1). 

2) The Safety and Mission Assurance Technical Authority (SMA TA) is a function of the 
Office of Safety and Mission Assurance (OSMA). SMA TA is delegated from the 
Agency’s Chief of S&MA to Center Directors and further delegated within the centers. 
Refer to NPR 7120.5E for details of the SMA TA. The OSMA manages NPR 8705.2B, 
which specifies many processes related to good HSI practice — e.g., requiring application 
of NASA-STD-3001 to human-rated P/P. NPR 8705. 2B also calls for establishing a 
formal HSI team for human space flight P/Ps that results in human-rated space flight 
systems. Pending updates to NPR 8705. 2B will add significant new information on HSI 
Team roles and responsibilities. 
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3) The Health and Medical Technical Authority (HMTA) is a function of the Office of the 
Chief Health and Medical Officer (OCHMO). The OCHMO promulgates the Agency’s 
human health and performance technical standards that must be met by programs and 
projects. Refer to NPR 7120.1 1, NASA Health and Medical Technical Authority 
(HMTA) Implementation, for details of the HMTA. HMTA is delegated from the 
Administrator to the Chief Health and Medical Officer (CHMO). HMTA is further 
delegated to center- level Chief Medical Officers (CMOs) at specific NASA centers. 
Each center CMO is the HMTA for P/P and programs at that center. At centers without 
an HMTA presence, the ETA and SMA TA have agreed to provide an insight function 
to alert the OCHMO of human systems issues within programs and/or projects at those 
centers. (Refer to NPR 7120. 5E and NPR 7120.1 1 for details of this process.) 

Uniquely, the HMTA for all human space flight programs and projects at all centers is 
delegated to the JSC CMO. The JSC CMO designates individuals as HMTA Delegates 
to each human space flight P/P. These HMTA Delegates are the authorized individual 
points of contact to implement the HMTA role for the P/P. To date, on major human 
space flight programs they have also typically been assigned as the program-funded HSI 
lead responsible party (see section 2.1.1, Programmatic Authorities) because of the close 
relationship between accomplishing HSI work and meeting the human health and 
performance technical standards applied to the P/P. 

The primary HMTA document related to the design and development phases of human space 
flight HSI is NASA-STD-3001, Space Flight Human-System Standard, Volume 1A, Crew 
Health, and Volume 2A, Human Factors, Habitability, and Environmental Health. The HMTA 
has the overall authority to maintain NASA-STD-3001, though all three NASA TAs must 
approve modifications to Volume 2. Additionally, HMTA personnel maintain NASA/SP-2010- 
3407, that accompanies NASA-STD-3001, NASA/TP-2014-218556, and this HSIPG, although 
this document is also coordinated through the Agency OCE HSI Steering Committee. 

Currently, NASA has not yet determined the method by which HSI will be integrated with the 
TA governance model. However, similar to where Human Rating reaches, HSI domains span 
each of the 3 TA domain areas, as shown in the figure in the “blue box” below. 
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2.1.3 Control Boards 

Control boards coordinate communication between institutional and programmatic authorities to 
reach agreements on specific program or project issues. The NASA Institutional TAs and the 
P/P-assigned HSI responsible lead participate in management control boards within a specific 
program or project. This provides the necessary and unique HSI technical input to P/P 
management to ensure that HSI is effectively accomplished and that the Agency’s institutional 
technical requirements are met throughout the P/P life cycle. For large, complex programs, there 
may be multi-level representation at control boards. For example, in NASA’s Exploration 
Systems Development (ESD) enterprise, element-level, vehicle-level, and program-level boards 
control specific technical content of the system under development, while cross-program control 
boards enable the highest levels of HSI that span across all the ESD programs. 

2.2 HSI in the NASA Program Management Structure 

NASA programs and projects are initiated and implemented to accomplish scientific or 
exploration goals that generally require a collection of mutually supporting projects. Programs 
integrate and manage these projects over time and provide ongoing support to enabling systems, 
activities, methods, technology developments, and feedback to projects and stakeholders. 
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Programs and Projects - Definitions 

a. Program — a strategic investment by a Mission Directorate or Mission Support Office that 
has a defined architecture and/or technical approach, requirements, funding level, and a 
management structure that initiates and directs one or more projects. A program implements 
a strategic direction that the Agency has identified as needed to accomplish Agency goals 
and objectives. 

b. Project — a specific investment identified in a Program Plan having defined requirements, a 
life-cycle cost, a beginning, and an end. A project also has a management structure and may 
have interfaces to other projects, agencies, and international partners. A project yields new 
or revised products that directly address NASA’s strategic goals. 


2.2.1 NASA Program Management and Systems Engineering Requirements 

NPR 7120.5E establishes the requirements by which NASA formulates and implements space 
flight programs and projects, consistent with the governance model contained in NASA Policy 
Directive (NPD) 1000.0B, NASA Governance and Strategic Management Handbook. 

Because the goals of programs vary significantly, different program implementation strategies 
are required, ranging from very simple to very complex. NPR 7120.5E allows for flexibility, but 
regardless of the structure of a program or project, NPR 7120.5E applies to the full scope of the 
program or project and all activities under it. Specific NPR 7120.5E requirements are flowed 
down to these activities to the extent necessary for the P/P to ensure compliance and mission 
success. Some P/P may be governed by NPR 7120.7, NASA Information Technology and 
Institutional Infrastructure Program and Project Management Requirements, and NPR 7120.8, 
NASA Research and Technology Program and Project Management Requirements (w/change 3 
dated 4/18/13). 

Systems engineering at NASA requires the application of a systematic, disciplined engineering 
approach that is quantifiable, recursive, iterative, and repeatable for the development, operation, 
maintenance, and disposal of systems integrated throughout the life cycle of a P/P. The 
emphasis of SE is on safely achieving stakeholder functional, physical, and operational 
performance requirements in the intended use environments over the system's planned life within 
cost and schedule constraints. 

NPR 7123. IB establishes common technical processes for implementing NASA products and 
systems, as directed by NPD 7120.4D, NASA Engineering and Program/Project Management 
Policy. NPR 7 123. IB complements the administration, management, and P/P reviews specified 
in NPR 7120.5E. NPR 7 123. IB is designed to clearly articulate and establish the requirements 
on the implementing organization for performing SE. 
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Systems Engineering is a logical systems approach performed by multidisciplinary teams to 
engineer and integrate NASA's systems to ensure NASA products meet customers' needs. 
Implementation of this systems approach is intended to enhance NASA's core engineering 
capabilities while improving safety, mission success, and affordability. This systems approach is 
applied to all elements of a system (i.e., hardware, software, human) and all hierarchical levels of 
a system over the complete project life cycle. 

Together, NPRs 7120.5E and 7 123. IB comprise the primary guidance within the Agency for 
managing NASA P/P. Many other discipline areas such as health and safety, medical, reliability, 
maintainability, quality assurance, information technology, security, logistics, and 
environmental, perform functions during project life-cycle phases that influence or are 
influenced by the engineering functions performed and need to be fully integrated with the 
engineering functions. The description of these disciplines and their relationship to the overall 
management life cycle are defined in other NASA directives and documents. To that end, NPR 
7123. IB and the accompanying NASA/SP-2016-6105 Rev 2 contain significant HSI language 
and references. 

2.2.2 Current HSI Documentation and Knowledge Resources for HSI 

Several documents contain elements of HSI that support the Agency commitment to include the 
human as part of the system definition. 

Table 2.2-1 NASA Documents with HSI Content 


Document 

HSI Content 

NASA Policy Directives / Procedural Requirements 

NPR 8705. 2B, Human-Rating 
Requirements for Space Systems 
(w/change 4 dated 8/21 /201 2) 

Processes, procedures, and requirements necessary to 
produce human-rated space systems that protect the safety 
of crewmembers and passengers on NASA space missions. 
For programs that require Human-Rating per this NPR, 
paragraph 2.3.8 requires the space flight program to form an 
HSI Team before SRR. 

NPR 71 23.1 B, NASA Systems 
Engineering Processes and 
Requirements 

Appendix A includes definition of HSI. 

Appendix G, Life cycle and Technical Review Entrance and 
Success Criteria, includes an HSI Plan. 

NPR 7120.5E, NASA Space Flight 
Program and Project 
ManagementRequirements 
w/Changes 1-1 3 

Establishes the requirements by which NASA formulates and 
implements space flight programs and projects, consistent 
with the governance model contained in NPD 1000. OB, NASA 
Governance and Strategic Management Handbook. Includes 
Human Rating requirements. 

NPR 71 20.1 1 , NASA Health and 
Medical Technical Authority (HMTA) 
Implementation 

Implements HMTA responsibilities to ensure that Agency 
health and medical policy, procedural requirements, and 
standards are addressed in P/P management when 
applicable and appropriate. 

NPR 8900. 1A, NASA Health and 
Medical Requirements for Human 
Space Exploration 

Establishes health and medical requirements for human 
space flight and the responsibilities for their implementation 
including health and medical, human performance, 
habitability, and environmental standards; sponsorship of 
health-related and clinical research. 
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Document 

HSI Content 


NASA Standards Documents and Handbooks 


NASA/SP-2007-61 05 Revl , NASA 
Systems Engineering Handbook 
(companion to NPR 7123.1) 

Describes SE as it should be applied to the development and 
implementation of large and small NASA programs and 
projects. (HSI is explicitly described.) 

201 6 update to SEHB 
(companion to NPR 71 23.1 B) 

Includes descriptions of HSI domains, life cycle activities, 
products, procedures, and practices. 

NASA/SP-2007-61 05, NASA 
Systems Engineering Handbook Wall 
Chart (2007 release) 

The SE Handbook wall chart provides an SE view of the 
project life cycle, including the phase-based SE engine 
processes. 

NASA-STD-3001 , NASA Space 
Flight Human System Standard 

OCHMO mandatory standard for NASA human space flight 
programs. 

Establishes Agency-wide requirements that minimize health 
and performance risks for flight crew in human space flight 
programs. 

Includes requirement [V2 3005] mandating that human space 
flight programs establish and execute a human-centered 
design process. 

NASA/SP-201 0-3407, Human 
Integration Design Handbook (HIDH) 

Guidance for the crew health, habitability, environment, and 
human factors design of all NASA human space flight 
systems. 

NASA/TP-2014-218556, Human 
Integration Design Processes (HIDP) 

HSI design processes, including methodologies and best 
practices that NASA has used to meet human systems and 
human-rating requirements for developing crewed spacecraft. 
HIDP content is framed around human-centered design 
methodologies and processes. 

NASA/SP-201 4-3705, NASA Space 
Flight Program and Project 
Management Handbook 
(companion to NPR 7120.5E) 

Contains context, detail, rationale, and guidance that 
supplements and enhances the implementation of space 
flight programs and projects, including an HSI Plan. 


In addition to the documents listed in Table 2.2-1, P/P-specific documents may be generated to 
capture HSI plans, requirements, strategies, etc. For example, the NASA ESD, Multi-Purpose 
Crew Vehicle (MPCV) 70024, Orion Multi-Purpose Crew Vehicle Human-Systems Integration 
Requirements, was generated as the program- specific instantiation of NASA-STD-3001 Volume 
2. In the International Space Station Program (ISSP), the ISSP-specific instantiation of NASA- 
STD-3000, Man-Systems Integration Standards (now superseded by NASA-STD-3001) is SSP 
50005, International Space Station Flight Crew Integration Standard (NASA-STD-3000/T). 
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2.3 Collaboration 

For the HSI practitioner, collaboration with the PM, Systems Engineer, other P/P team leads, and 
the overall Program Management and SE infrastructure is the most appropriate and efficient 
means of ensuring HSI is a core part of every P/P. The goal of working within an agreed upon 
structure is to enable P/P stakeholders and experts from varied disciplines to consider and 
address relevant issues and challenges of shared concern and resolve design trades in a rational 
and cooperative environment. The purpose of working collaboratively is to create an ideal, 
shared vision that all stakeholders can agree upon, commit to, and finally create action plans to 
support. 

It is essential for the HSI practitioner to collaborate with many elements of the P/P, as well as 
with relevant institutional organizations where HSI domain SMEs are likely located. HSI is 
inherently part of the larger P/P’s Systems Engineering and Integration (SE&I) infrastructure and 
has a natural collaborative role with system engineers in defining the P/P’s mission and in 
designing the total system (human + hardware + software) needed to perform the mission. 
Conceptual design, architectural formulation, function allocation, and operations development 
are all desired processes and outcomes of early collaboration. HSI collaboration continues 
through all P/P phases, using NASA SEE processes outlined in NPR 7123.1B and the SEHB. 

2.3.1 Integrated Product Team and Working Group Participation 

Within a P/P, the HSI practitioner must collaborate with many teams. In Pre-Phase A of the P/P 
life cycle (see section 4.1 of this guide), the HSI team should play an integral role in defining and 
refining the system’s Concept of Operations (ConOps). Beginning in Phase A and throughout 
the P/P life cycle, HSI Integrated Product Teams (IPTs) and Working Groups (WGs) participate 
in design trades and system maturation activities. HSI participation in these teams is critical for 
providing timely human-centered input to the design process. The HSI practitioner has a close 
collaborative relationship with (HH&P), S&MA, Engineering, Flight Crew, Ground Support, and 
Mission Operations teams and their TAs as deemed appropriate. HSI team members participate 
in the efforts of these other teams via IPTs and WGs and make valuable contributions in order to 
remain relevant to the program or project and to instill HSI value in all areas. 

Refer to section 4.3.2, Organizing the HSI Team, and section 4.4.3, Integration of Subject Matter 
Expertise for HSI Activities, in this guide for additional details on HSI teaming. 

2.3.2 HSI Team Collaboration 

Because of the number of human-centered disciplines that the HSI practitioner can and should 
bring to realization, it is likely that HSI will itself comprise a team, either informally or formally 
recognized by the program or project, e.g., a P/P-designated HSI IPT. Within the HSI team, 
extensive interdisciplinary collaboration is required. HSI includes both highly qualified SME 
personnel who understand details of human characteristics and HSI integrators who know the SE 
and programmatic methods required to integrate human performance and capacities into the 
P/P’s mission and resulting systems’ design, development, and implementation. 

A wide range of SME knowledge is integrated by the HSI practitioner in order to create products 
useful to the P/P. Depending on the nature of the P/P, these SMEs may provide expertise on 
many specific areas of human health and performance such as those listed in Table 1.6-1. 
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2.4 HSI and Systems Engineering 

Given the level of defined structure for NASA P/P management and SE in NPR 7120.5E and 
NPR 7123. IB, respectively, the HSI practitioner is advised to learn the details of these top level 
requirements documents and learn to integrate HSI concerns into their frameworks through 
collaboration and through developing processes and products that mesh with P/P management 
and SE. The next chapter of this document describes HSI activities, processes, and products that 
need to or are appropriate to occur at each step of the NASA SE process. As noted in section 
1.3, History of HSI, in 2015 the Agency HSI community worked to insert HSI-specific language 
into an update to NASA/SP-2007-6105, including identifying HSI products and processes 
appropriate for every step of SE. This guide compiles and expands on this information in order 
to provide the HSI practitioner a concise methodology for performing HSI in a P/P environment. 

A highly summarized overview of HSI as applied to the NASA SE Process is provided below as 
a general reference: 

• Concept Development: Participating early to ensure HSI considerations are included in 
conceptualization (e.g., function allocation to humans, support analysis of alternatives, 
flight and ground crew projections, human risk assessment). 

• Requirements Definition: Being a vital part of the system capabilities and specification 
definition process. Write clear, concise, and testable HSI-related capabilities and 
specifications to ensure the human-allocated functions and risks are addressed. 

• Design Development: Participate in the design process of systems to ensure HSI 
principles are incorporated into design decisions such that system trade-offs do not 
marginalize human considerations. 

• Testing and Evaluation: Conduct verifications of HSI-related system requirements and 
validation in an operational context to evaluate whether the system adequately facilitates 
human performance in meeting total mission performance goals. 

• Sustainment/Closeout: Continue the system support process to ensure HSI concerns are 
addressed through operational lessons learned, engineering changes, training 
improvements, etc. 
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2.5 HSI Team Application of Tools, Models, and Analyses 

The HSI Practitioner is responsible for ensuring that appropriate technical models and tools are 
available to the P/P HSI team in order to accomplish its analytical work. The HSI Practitioner 
should include these models and tools in the team planning and budgeting, and ensure that the 
necessary SMEs are engaged to apply the tools. The broad scope of HSI means that many 
models and tools may be candidates for application on a P/P, but a subset will be selected by the 
HSI team based on the specific P/P needs, processes, and budget. Results and analysis from use 
of HSI models and tools can be used in early phase decision making for architecture, design, 
prototyping, and requirements, and in later phases can support verification and validation 
(V&V). 

There are several key aspects of HSI models and tools: 

• Selected based on the needs of P/P and readily available to the HSI team. 

• Supportive of the full P/P life cycle including architectural trades, conceptual to detailed 
design, risk analysis, system performance analysis, HITL testing and demonstration, 
system development, and mission operations. 

• Enables collaboration: the tools produce HSI analytical outputs that are suitable as input 
to other P/P tools or processes. 

• Validated/accredited for their intended uses (per NASA-STD-7009, Standard for Models 
and Simulations). 

Table 2.5-1 lists some examples of analytical tools used for various aspects of HSI. The tools to 
be applied in a P/P will be documented in the HSI Plan or HSI section of the SEMP. 


Table 2.5-1 Representative Examples of HSI Tools 


General Type 

Specific Examples 

Human error analysis 

Cognitive Reliability and Error Analysis Model (CREAM) 

Workload 

Bedford evaluation scale, NASA TLX, or other HITL 

analysis/evaluation 

measures 

Usability analysis/evaluation 

System Usability Scale (SUS) or other HITL measures 

Anthropometric analysis 

Population analysis, worksite analysis 

Task analysis/evaluation 

Discrete event simulation 

Requirements management 

3SL Cradle or other products 

Lighting 

Radiance modeling 

Acoustics 

Statistical energy analysis and modeling 

Radiation 

NASA space cancer risk projection models 

Environmental analysis 

Water, air, microbial sampling/analysis methods 
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General Type 

Specific Examples 

Physiologic analysis 

JSC 331 24/CTSD-SH-91 8, 41 -Node Transient Metabolic 
Man Program, Computer Program Documentation, 
Wissler human thermoregulation analysis - 
Decompression sickness Bubble Growth Model 

Medical care planning 

NASA Integrated Medical Model 
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3.0 HSI IN THE NASA SYSTEMS ENGINEERING ENGINE 

The primary focus of HSI is to recognize and give weight to HSI considerations, identify human 
performance needs and constraints, and develop HSI requirements. To have impact, these 
activities must be performed in the early phases of the life cycle. In this section, opportunities to 
recognize and manage HSI while drafting capability documents during early phases and at major 
phase key decision points will be discussed. The approach will incorporate both NASA SEE 
processes and NASA Life Cycle Phases. 

3.1 Engine Processes Overview 

The 17 NASA SEE processes are detailed in NPR 7123. IB. The SEHB and wall chart show 
how the SEE processes are integrated within each life cycle phase and repeated across multiple 
life cycle phases. 

Table 3.1-1, SEE Mapping To Systems Engineering Handbook and NPR, is a useful resource 
when drilling down into the SEE process flow details, and provides a map between the SEE 
number, the SEHB section number, and the NPR 7 123. IB section number. These numbers are 
also cross-linked in many of the tables in this chapter. 

The practitioner should note that NPR 7123. IB provides detailed steps with process inputs and 
outputs for each of the 17 SEE processes. 


Table 3.1-1 SEE Mapping To Systems Engineering Handbook and NPR 


Life Cycle 
Group 

SEE 

No. 

SEHB 
Section No. 

Process Title 

NPR 7123.1 B 
Section No. 

System 

Design 

Processes 

1 

4.1 

Stakeholder Expectations Definition 

C.1.1 

2 

4.2 

Technical Requirements Definition 

C.1.2 

3 

4.3 

Logical Decomposition 

C.1.3 

4 

4.4 

Design Solution Definition 

C.1.4 

Product 

Realization 

Processes 

5 

5.1 

Product Implementation 

C.2.1 

6 

5.2 

Product Integration 

C.2.2 

7 

5.3 

Product Verification 

C.2.3 

8 

5.4 

Product Validation 

C.2.4 

9 

5.5 

Product Transition 

C.2.5 

Technical 

Management 

Processes 

10 

6.1 

Technical Planning 

C.3.1 

11 

6.2 

Requirements Management 

C.3.2 

12 

6.3 

Interface Management 

C.3.3 

13 

6.4 

Technical Risk Management 

C.3.4 

14 

6.5 

Configuration Management 

C.3.5 

15 

6.6 

Technical Data Management 

C.3.6 

16 

6.7 

Technical Assessment 

C.3.7 

17 

6.8 

Decision Analysis 

C.3.8 
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The approach used in this document is to utilize the NASA SEE to execute HSI activities and 
products. Table 3.1-2 lists the 17 SEE processes and maps them to HSI points of emphasis. This 
is a summary level view and will be expanded greatly in the following sections. 


Table 3.1-2 Mapping HSI into the SE Engine 


SYSTEM DESIGN PROCESSES 

HSI EMPHASIS 

Requirements Definition Processes 

Stakeholder Expectations Definition (1) 
Technical Requirements Definition (2) 

Function allocation between and among systems 
and humans, define roles and responsibilities, 
develop requirements, baseline ConOps 

Technical Solution Definition 

Logical Decomposition (3) 
Design Solution Definition (4) 

Function allocation (during decomposition), 
ConOps and operations goals, iterative human- 
centered design, task analysis, design prototyping 
for HITL evaluation, operate-to documents 

PRODUCT REALIZATION PROCESSES 

HSI EMPHASIS 

Design Realization Processes 

Product Implementation (5) 
Product Integration (6) 

Validate design for all human-systems interactions 
as elements are integrated 

Evaluation Processes 

Product Verification (7) 
Product Validation (8) 

HITL Testing, validation to ConOps 

Product Transition Processes 

Product Transition Process (9) 

Prepare for Operations: training, simulations, 
handing and operations documents 

TECHNICAL MANAGEMENT PROCESSES 

HSI EMPHASIS 

Technical Planning Processes (10) 

LCC management 

Technical Control Processes (11-15) 

HSI participation in management processes, as 
required 

Technical Assessment Process (16) 

HSI products, entrance, and exit criteria for 
milestone reviews; TPM examples 

Technical Decision Analysis Process (17) 

Human-centered design, HSI domain participation 


A depiction of HSI product inputs and outputs from the SEE processes using the NASA/SP- 
2007-6105 wall chart process flow diagram shown in Figure 3.1-1, Systems Engineering Engine 
with HSI Inputs and Outputs, with additional text added for HSI. This diagram will be 
referenced in the following sections to explain both SEE and by-phase activities to be conducted 
by the HSI practitioner. And as noted in section 1.2, the depictions and descriptions provided in 
the HSIPG attempts to aid the reader in understanding a complex, iterative, and recursive 
process. The reader is encouraged to use the SEHB and other sources to accompany the HSIPG . 
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SEE 5 
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Implementation 
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Next 
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Tier 


SEE 6 
Product 
Integration 


Handling Docs 


From /To i 
All Technical! 
Processes | 



SEE 10 

Technical Planning 

HSI Plan or SEMP inputs 

Life Cycle Cost Estimates 


SEE 11 Requirements 
Management 


SEE 12 

Interface Management 


SEE 13 Technical Risk 
Management 

HSI Domain Risks 


SEE 14 Configuration 
Management 


SEE 15 Technical Data 
Management 

Lessons Learned Reports 


SEE 16 

Technical Assessment 

l 

SEE 17 

Decision Analysis 

Human Assessments 

Design meets ConOps? 


Figure 3.1-1 Systems Engineering Engine with HSI Inputs and Outputs 


The HSI products shown as inputs and outputs in Figure 3.1-1 are highly condensed. The by- 
Phase sections of this guide use this diagram, but also refer to products in Table 3.1-3, Product 
Maturity Matrix for Programs and Projects. This list contains the most common products, but it 
should be noted that a complete list of products would be developed by the practitioner and 
documented in the HSI Plan. The HSI Plan should be updated as required when new products 
are identified. The maturity of these products is based on NPR 7120.5E. 

In addition, Table 3.1-4, Product Maturity Matrix for Human-Rated Programs, is provided from 
NPR 8705. 2B. This list will provide additional insight into the types of products required for the 
health, safety, and performance of humans engaging in operating and living in human-rated 
space vehicles. 
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Table 3.1-3 Product Maturity Matrix for Programs and Projects 


Phase 

Pre-A 

A 

B 

c 

D 

E 

F 

Milestone Review 
Product 

MCR 

SRR 

SDR / 

PDR 

CDR / 

SIR 

TRR 

SAR 

ORR 

FRR 

PLAR/ 

CERR 

DR/ 

DRR 

MDR 

PRR 

Conceptualization and Architecture 

Concept Documents, ConOps 

D 

1 

U 

U 









Function allocation to Humans 
(Flight Architecture) 

D 

1 

U 

U 









Function allocation to Humans 
(Ground Architecture) 

D 

D 

1 

u 









HSI Decomposition Models for 
Requirements Development 

D 

U 

u 

u 









HSI Requirements (Project and System) 

D 

1 

u 

u 









HSI Requirements (Subsystem) 

D 

D 

D 

1 









HSI inputs to technology maturation 

1 

U 

U 

u 

U 








Human mockups, models, prototypes 

X 

X 

X 

X 

X 

X 







Human Assessments, 
Human-systems interactions 



X 

X 

X 

X 







Validate design to ConOps 



X 

X 

X 

X 


X 


X 

X 


Cross-cutting and Manac 

ement 

HSI Planning for SEMP or HSI Plan 

D 

1 

u 

u 

u 

u 







HSI-applicable Trade Study reports 

X 

X 

X 

X 

X 

X 







Measures of Effectiveness (MOEs) 

D 

D 

1 

u 

u 

u 







Measures of Performance (MOPs) 

D 

D 

1 

u 

u 

u 







Technical Performance Measures (TPMs) 

D 

D 

1 

u 

u 

u 







Life Cycle Cost Estimates 

D 

D 

1 

u 

u 

u 

u 

u 

u 

u 

u 

U 

HSI Domain Risks 

1 

U 

u 

u 

u 

u 

u 

u 

u 

u 

u 

U 

Lessons Learned Reports 

X 


X 

X 


X 




X 

X 

X 

Production and Operations 

Operations Concept 

D 

D 

D 

1 

u 

u 


u 

u 




Human-in-the-Loop Testing 




X 

X 

X 

X 

X 





Operate-to Documents 



D 

D 

1 

u 

u 

u 

u 




Logistics Documents 



D 

D 

1 

u 

u 

u 

u 




Handing and Ops Documents 





D 

1 

u 

u 

u 

u 



Monitoring of human performance 








X 

X 

X 

X 



Legend: D - Draft, I - Initial baseline, U - Update, X - Applicable 
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Table 3.1-4 Product Maturity Matrix for Human-Rated Programs 


Phase 

Pre-A 

A 

B 

c 

D 

E 

F 

Milestone Review 
Product 

MCR 

SRR 

SDR / 

PDR 

CDR/ 

SIR 

TRR 

SAR 

ORR 

FRR 

PLAR/ 

CERR 

DR/ 

DRR 

MDR 

PRR 

Human Rating Products and Activities 

Human-Rated Space System Description 


1 











Reference Missions Description 


1 











Safety and Mission Assurance Processes 


1 

U 

U 

u 








Program's Utilization of Flight Crew 


1 











Human-Rating Requirements 
Implementation Plan 


1 

U 

U 

u 








HSI Team Plan 


1 











Mandatory Technical Standards Listing 


1 











Technical Standards Tailoring Summary 


1 











Human-Rating Tailoring List 


1 

u 

u 

u 




U 




Safety Analysis Influence Summary 



1 

u 

u 








Crew Survival Approach Description 



1 

u 

u 








Probabilistic Safety Requirements 


1 

u 

u 

u 




u 




Crew Survival Strategy Effectiveness 
Summary 



1 

u 

u 




u 




Safety Risk Ranking and Probabilistic 
Safety Requirements Achievement 
Analysis 



1 

u 

u 




u 




System Failure Tolerance Summary 



1 

u 

u 




u 




Crew Workload Evaluation Plan 



1 

u 

u 








Preliminary Flight Testing Plan 



1 










Human System Performance Testing 
Influence Summary 




1 

u 








Human Error Analysis Influence 
Summary 




1 

u 




u 




Flight Testing Plan and Objectives 




1 

u 








Verification and Validation Plan for 
Human Rating Requirements 


1 

u 

u 

u 




u 




Human Rated System Configuration 
Control and Maintenance Plan 









1 




Verification and Validation Results 
Summary for Human Rating 
Requirements 









1 




Flight Testing Results Summary 









1 




Crew Workload Evaluation Results 









1 




Post-Verification/Validation Safety 
Analysis Influence Summary 









1 




Legend: D - Draft, I - Initial base 

ine, U - Update, X - App 

icab 

e 
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3.2 By-Phase Activities and Products 

The sections in this chapter are subdivided by life cycle phase since the 17 SEE processes are 
executed in multiple phases, which supports the iteration and recursive execution of SEE 
processes. 

In each phase of the P/P, the HSI practitioner must be product-oriented in order to add distinct, 
recognizable value. Tangible products must be planned and executed on schedule and to the 
necessary phase-based maturity in order for HSI to be a key player in SE, in design efforts, and 
in mission operations. The by-phase sections will focus on both the SEE processes and product 
maturity goals, since products typically cut across life cycle phases. 

As each product or activity is introduced for the first time, regardless of phase, additional detail 
and reference information will be provided. 

3.3 Pre-Phase A: Concept Studies 

3.3.1 Pre-Phase A Objectives 

The key purpose of Pre-Phase A is to “produce a broad spectrum of ideas and alternatives for 
missions from which new P/Ps can be selected” (NASA/SP-2007-6105). The Pre-Phase A 
period is when users and stakeholders for a project or program are identified, high level 
requirements are compiled, preliminary design reference mission concepts are composed, 
possible ConOps developed, key capabilities of the systems are listed, and when request for 
proposal and contract-related details and deliverables for a future solicitation may be initially 
considered. 

In order to fully appreciate the scope and nature of activities conducted during the Pre-Phase A 
part of the life cycle, the practitioner must understand SEE processes but also should review the 
detailed SEE diagram provided as an insert with NASA/SP-2007-6105 (see Table 2.2-1). It is 
also available online, see the References in Appendix D. An examination of the processes used 
in Pre-Phase A through Phase B (for Program Formulation) will show that in addition to the four 
system design processes (NASA/SP-2007-6105 section 4), five product realization processes 
from NASA/SP-2007-6105 section 5 are also performed, as well as the eight cross-cutting 
processes from NASA/SP-2007-6105 section 6. In the fold-out diagram, the practitioner will 
find that the activities listed for each SEE process are tailored to be appropriate for each phase. 


Pre-Phase A NASA Systems Engineering Goals 

• Produce a broad spectrum of ideas and feasible 
alternatives 

• Determine feasibility based on cost, schedule, 
technical, and risk studies 

• Establish mission needs, goals, and objectives 
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Review milestones and Key Decision Points (KDPs) for all phases are defined in section 2.3 of 
NPR 7120.5E. For Pre-Phase A, the Mission Concept Review (MCR), which supports KDP A 
for projects, is conducted near the end of Pre-Phase A. 

MCR Entrance and success criteria are provided in NPR 7 123. IB, Table G-3. 

The MCR success criteria are fundamentally a review of the products of the activities conducted 
in Pre-Phase A. Ultimately it is up to the “Decision Authority” to determine if the P/P is mature 
and ready to progress to the next phase of the life cycle. For smaller projects, there may be a 
desire to go straight into Phase A and use the System Requirements Review (SRR) as the first 
KDP and milestone. In this case, it is strongly advised that an informal concept review be held 
to ensure that the concept “point of departure” is adequately communicated with stakeholders, 
domain experts, and team members before proceeding forward to make critical high level design 
decisions. It is also advised that Pre-Phase A activities and products should not be “skipped.” 

It is critical that HSI practitioners actively engage in Pre-Phase A activities, reviews, and 
decisions to avoid costly revisions due to inadequate consideration of the human component of 
the P/P. The human-oriented mission goals, concepts, high level requirements, capabilities, and 
constraints must be clearly defined. Early inclusion of HSI practitioners ensures that the system 
concept is optimized for the developers, maintainers, trainers, and other system stakeholders in 
addition to end users. Domain personnel and SMEs can provide best practices and solutions for 
issues during concept development rather than later in system design when changes are more 
costly and more difficult to implement. 

There are several HSI-related activities that must be initiated or completed during Pre-Phase A. 
Per Key Concept #4, listed in section 1 .4, getting started with HSI activities early is a best 
practice and necessary to achieve the cost reductions (avoidance) to LCC. Incorporating HSI 
early sets the stage for a successful design — one that accommodates humans, rather than forces 
the humans to accommodate to the design. A list of important HSI activities is provided in this 
section. These activities are not strictly HSI activities; with a few exceptions, HSI does not 
typically “own” system-level documents such as the ConOps, SEMP, and domain- specific 
documents. HSI practitioners generally work inside the SE process to provide inputs for SE 
products. 

The relevant goals for the HSI practitioner during this phase are shown in Table 3.3-1. 
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Table 3.3-2 Goals and Success Mapping for HSI in Pre-Phase A 


Milestone 

HSI Goals 

HSI Success Criteria 


Elicit Stakeholder Goals 

Captured and quickly matured, 
including any provided 
requirements, concepts, 
constraints, budgets, timelines, 
etc. 


Support Function allocation to 
Humans 

Must be identified early in the 
planning for any system, but try 
to avoid any “solution bias.” 


Develop Operational Concepts 

Developed and evaluated 
against stakeholder 
expectations and other P/P 
criteria to support development 
of the ConOps. 

MCR 

Identify Design Constraints 

Document HSI factors, such as 
the number and skills of users, 
types of human interfaces, 
logistics infrastructure, 
maintainability, and training. 

Produce HSI Requirements 

Captured at a high level along 
with stakeholder expectations 


Initiate HSI Planning 

Initiated to set up resources to 
produce key products 
(standalone HSI Plan or input 
into the SEMP) 


Support Feasibility Activities 

Conducted, which can include 
human-centered mockups, 
models, analysis, and 
simulations to support validation 
of a concept and drive 
considerations for alternative 
concepts. 


Create Metrics and Measures 

Captured to provide human 
effectiveness and performance 
criteria for the proposed 
solutions (matured in the next 
phase) 


Operational Concepts, as used above, can be in the form of mission scenarios, which include 
normal operations, as well as scenarios for emergency “off-nominal” and contingency 
operations. As these scenarios are developed, assumptions and conceptual decisions are made 
regarding how the goals and scenarios are accomplished. Functions can be allocated to 
hardware, software, and humans to create a system architecture concept. HSI practitioners 
engage to guide these decisions using best practices, analysis, and assessments for workload, 
human performance, reliability, and other criteria. The work is collaborative and broad, 
coordinating with domain experts and stakeholders. 
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3.3.2 Pre-Phase A Process and Products 

Most activities in Pre-Phase A flow down from the primary stakeholder “Goals, Requirements, 
Human Allocation” activities. Performing the Pre-Phase A processes will produce HSI-related 
products that then support activities in repeated iterations of concept evaluation or in later 
phases. Figure 3.1-1 is provided as a summary view of processes to be performed. HSI is 
distinguished from HFE practice in that HSI is “all about process.” All of the SEE processes are 
important, but some processes involve the HSI practitioner more than others. The relevant 
processes for the HSI practitioner during this phase are shown in Table 3.3-2. Refer to the 
SEHB, the SEHB wall chart, and NPR 7 123. IB for supporting details. NPR 7 123. IB also 
provides detailed process flow diagrams documenting the activities as well as the inputs and 
outputs for each activity. 

Table 3.3-3 Process-Product Mapping for HSI in Pre-Phase A 


SEE 

Process 

Process Title 

Key HSI Activities 

Major HSI Products 
Per Milestone 

1 

Stakeholder 

Expectations 

Establish ConOps and 
support strategies for use over 
the systems’ life, including 
allocation to humans 

MCR: HSI inputs to mission and 
architecture, and ConOps (initial 
draft) 

Analyze expectations to 
establish MOEs for customer 
satisfaction 

MCR: initial set of MOEs defined 

2 

Technical 

Requirements 

Define design and product 
use constraints 

MCR: Function allocation to 
humans; HSI inputs to 
requirements for mission, 
science, and top-level system 

Define functional and 
behavioral expectation in 
technical terms per 
ConOps/usage 

Define technical requirements 
in acceptable “shall” 
statements 

3 

Logical 

Decomposition 

Define logical decomposition 
models (e.g., operator tasks) 
for derived requirements and 
validate 

MCR: Initial concepts for 
decomposition; models used to 
derive HSI requirements 

4 

Design Solution 

Define and analyze alternative 
design solutions for context of 
use and LCC 

MCR: HSI inputs to technology 
and maturation strategies 

Verify the fully defined design 
solution 

5 

Product 

Implementation 

Produce early-phase reports, 
mockups, models, prototypes, 
and demonstrators 

MCR: Support development of 
products used for human 
assessments 

10 

Technical Planning 

Produce HSI content for 
SEMP and other technical 
plans 

MCR: HSI Planning initiated; 
preliminary inputs to HSI Plan or 
SEMP, or equivalent 
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SEE 

Process 

Process Title 

Key HSI Activities 

Major HSI Products 
Per Milestone 

17 

Decision Analysis 

Conduct decision analysis 
process for identified technical 
issues including HSI concerns 

MCR: Support architecture and 
mission trade-offs and analysis; 
coordinate decisions to allocate 
functions to humans 


Several HSI-related products must be initiated or completed during Pre-Phase A. It should be 
noted that projects that have a significant human component required to achieve potentially 
hazardous missions may require multiple “passes” and concept design assessments. This can 
produce multiple assessment reports, multiple mockup configurations, and launch/landing 
models with thousands of simulation data runs, just to give a few examples. 

These products are developed by executing the steps shown in Figure 3.1-1, Systems 
Engineering Engine with HSI Inputs and Outputs, which is based on NASA/SP-2007-6105 and 
wall chart, with HSI details added. 

The process starts with SEE 1, Stakeholder Expectations, to elicit needs, goals, and objectives 
for the product and mission. The HSI practitioner will be focused on identifying the touch- 
points, interfaces, and systems where humans are involved or allocated to perform functions. 
The primary product from SEE 1 is the operations concept, which is eventually placed into the 
ConOps document. See chapter 4.4.2 of this document for more information on supporting 
ConOps development. 

The second key product for the HSI practitioner will be to generate candidate measures of 
effectiveness (MOEs) that involve human participation. See chapter 4.4.5 of this document for 
developing and using HSI metrics. 

Development of requirements using the stakeholder inputs and operations concepts is performed 
under SEE 2, Technical Requirements. Note: This does not include requirements management, 
which is SEE 11. As for all of the SEE processes, refer to NPR 7123. IB for detailed steps, 
inputs, and outputs. For Pre-Phase A, the requirements remain at a high level and the HSI input 
is focused on function allocation, which will support developing requirements in later phases. 
See Table 4.4-2, Function allocation Process, for details on performing function allocation 
activities with HSI considerations. 
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Typically, domain participation is ensured through collaboration when developing requirements. 
Although an HSI team can be formed during Pre-Phase A for larger Programs, typically the work 
is performed by domain and subject matter experts. Often the requirements, constraints, 
measures of performance (MOPs), and technical performance measures (TPMs), and related 
products are classified as “candidate” during this phase. See section 4.4.4 for developing HSI- 
based requirements, and section 4.3.2 for organizing the HSI team. 

Some HSI products can be delayed to Phase A for the first draft, but most will have materials 
produced and planning accomphshed in this phase. If the P/P is human rated, then the additional 
programmatic requirements are levied for compliance (e.g., HSI team stood up by SRR per NPR 
8705. 2B). Capturing the planning materials produced during Pre-Phase A is important to be able 
to feed into the HSI Plan, if written, or the SEMP or similar engineering management document. 
This activity is performed under SEE 10, Technical Planning, which is a cross-cutting process. 
See HSIPG section 4.4. 1 on writing the HSI Plan. 

The products from SEE 1 and SEE 2, along with other decisional information, will feed SEE 3, 
Logical Decomposition, activities. During Pre-Phase A, the HSI practitioner should start to 
identify which mechanisms and models will be used to strategically derive and decompose 
detailed requirements. These methods can include a variety of human assessments from low- 
fidelity mockups, task analysis, human constraints and standards, human-centric design 
guidance, etc. For a list of these types of resources, refer to the References in Appendix D. See 
section 4.4.7 for ensuring the usability of systems and section 4.3.4 on identifying human- 
centered trade-offs. 

The Design Solution process, SEE 4, follows next and uses the Pre-Phase A products to develop 
the set of potential solutions, recommended architectures, and inputs to the technology and 
maturation strategies. The HSI practitioner participates to ensure the design solution options are 
validated against the human goals and objectives, and concept documents. Plus the HSI 
practitioner can ensure that any LCC analysis includes the full scope of the life cycle, which 
includes an evaluation of the cost of operational resources and activities for each design 
alternative. This work is supported by SEE 17, Decision Analysis, which uses the Pre-Phase-A 
products as inputs, and provides overall decisional outcomes for the P/P. See HSIPG sections 
4.4.9 and 4.4.10 for LCC as it applies to HSI. 

While not explicitly listed in Table 3.3-2, the HSI practitioner should also participate in SEE 13, 
Technical Risk Management, which also includes risk analysis activities. 

Prototyping and modeling can be extensive for projects, which combine human habitability, 
operations, and conducting science such as a crew vehicle or similar manned platform. These 
physical products are produced in SEE 5, Product Implementation. Figure 3.3-1 is a photograph 
of a crew vehicle mockup that was used in an HITL to analyze access, reach, and visual 
perception. As you can see, a modest investment was made to construct a structurally stable 
model that could be reconfigured inside. Figure 3.3-2 shows a mockup for an aviation cockpit 
for evaluation of pilot performance. The pilot is outfitted with an eye-tracking device to gain 
insight into both the layout and human performance when managing concurrent tasks. While 
some HITL mockups can and should be elaborate, in many cases prototypes need not be overly 
detailed or costly to provide valuable design information. The systems engineer should be well 
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aware that the end product includes not only the final deliverable, but enabling products as well. 
A rocket cannot be sent to space without the availability of an integration and assembly facility. 
Also, reducing risk is a key component of human space flight; mockups and models are stepping 
stones along the way to both successful, well-crafted solutions and for ensuring the safety of the 
operators. 



Figure 3.3-1 Example: Crew Vehicle Mockup 



Figure 3.3-2 Example: Cognitive Performance in Aviation Environment 
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Although not explicitly listed in Table 3.3-2, additional product realization processes are 
executed as shown in Figure 3.1-1 to verify, validate, and integrate (SEE 6) any products created 
in SEE 5, Product Implementation. The HSI practitioner may be involved in these processes. 

For Pre-Phase A, SEE 7, Product Verification and SEE 8, Product Verification, are usually 
limited to products produced in the phase, for example mockups and models. 

3.4 Phase A: Concept & Technology Development 

3.4.1 Phase A Objectives 

The key purpose of Phase A is to “determine the feasibility and desirability of a suggested new 
major system and establish an initial baseline compatibility with NASA’s strategic plans” (per 
NASA/SP-2007-6105). This is a stage in which the mission concept from Pre-Phase A is 
revisited in a more formal fashion, with increased emphasis towards conceptual development, 
engineering details, technical risks, and allocation of functions to various systems and sub- 
systems. The goals for Phase A from the NASA/SP-2007-6105 wall poster are shown in the 
“blue box” that follows to provide a reference for the phase from a high level perspective. 


Phase A NASA Systems Engineering Goals 

• Develop baseline mission concept 

• Demonstrate feasibility of selected concept 

• Establish validated requirements that meet mission 
objectives 

• Establish architectural product design 

• Allocate requirements to next lower level 

• Identify needed technologies 

• Mitigate technical risks 


In Phase A, the work that was completed in Pre-Phase A is used to begin the more formal work 
and rigor required of space flight P/Ps. This is still early in the P/P life cycle, so decisions made 
here are critical and greatly affect LCC. The architects, designers, and SMEs are still given 
“room” to assess alternative design solutions during the beginning of the phase. By the end of 
the phase, the concepts, documents, requirements, and solutions become firm as system trades, 
assessments, technology selection and solutions iterate back and forth in the effort to seek the 
most cost-effective designs. The result of the phase is an accepted baseline design, which is 
achieved through the two life-cycle reviews, the SRR and the System Design Review (SDR). 
Robotic missions use the Mission Design Review (MDR) in place of the SDR. HSI is still 
applicable to robotic missions. 

The SRR is generally a mid-phase review. The SRR precedes the MDR or SDR. 


3-13 



HSI Practitioner's Guide 


The MDR or SDR support the KDP B milestone. For programs, the SRR and SDR support the 
KDP 0 milestone. Entrance and success criteria are provided in NPR 7123.1B, Appendix G, as 
follows: 

• Table G-l - SRR for a Program 

• Table G-4 - SRR for Projects or Single-project Programs 

• Table G-2 - SDR for a Program 

• Table G-5 - MDR/SDR for Projects and Single-project Programs 


In the event that the MCR was not held during Pre-Phase A, HSI practitioners are strongly 
advised to communicate the concepts and human performance goals to stakeholders, domain 
experts, and team members, well in advance of SRR to ensure that the human component is 
taken into consideration for the Phase A work flow. For SRR and MDR/SDR, HSI practitioners 
support the reviews with HSI-related product submissions, as defined in the HSI Plan, as peers to 
communicate HSI details when required, and as evaluators to ensure compliance to best practices 
and standards. 

Phase A goals and success criteria are mapped to relevant milestones in Table 3.4-1. 

Table 3.4-1 Goals and Success Mapping for HSI in Phase A 


Milestone 

HSI Goals 

HSI Success Criteria 

SRR 

Support Function allocation to 
Humans 

Completed for all established 
architecture levels 

Establish HSI Team 

(required for Human-rated Programs 

and recommended for most Projects) 

HSI Team Roster includes Lead 
and all necessary SMEs 

Generate HSI Requirements 

HSI design constraints, human 
interfaces, and objectives for all 
relevant domains are 
addressed in requirements 

Support Concept of Operations 

HSI Inputs Incorporated into 
ConOps 

SDR/ 

MDR 

Initiate HSI Planning 

Key HSI products and HSI 
resources are documented in 
HSI Plan, or as input to SEMP 
or other project plan document 

Support Feasibility Assessments and 
Modeling 

Human-centered mockups, 
models, simulations and 
analyses are utilized to drive 
lower level requirements and 
design trades 
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3.4.2 Phase A Process and Products 

The activities performed in Phase A are similar to those performed in Pre-Phase A. Indeed, 
smaller projects can easily lose the distinction between these two early phases as the milestone 
and decision gate for Pre-Phase A, the MCR, is often ignored in favor of the first Phase A KDP 
milestone, the SRR. A review of the tailoring of the activities performed in Phase A as shown in 
the wall-chart provided with NASA/SP-2007-6105 shows moving from candidate architecture, 
requirements, and solutions in Pre-Phase A to selected and baselined architecture, requirements, 
and solutions in Phase A. 

A second distinction between Pre-Phase A and Phase A lies with the depth of decomposition: 
Phase A activities will iterate to a lower and more detailed level, having completed selection of 
higher level parts of the design. 

As the P/P is matured, the ability to perform additional processes is made available. For 
example, firming the architecture allows for the development of TPMs, improved LCC 
estimates, higher fidelity models and mockups, and the creation of product baselines. 

HSI practitioners will be called upon to engage in activities as shown in Table 3.4-2, Process- 
Product Mapping for HSI in Phase A. Some activities and products are similar to those in Pre- 
Phase A. 


Table 3.4-2 Process-Product Mapping for HSI in Phase A 


SEE 

Process 

SEE Process Title 

Key HSI Activities 

Major HSI Products 
Per Milestone 

1 

Stakeholder 

Expectations 

Establish ConOps and support 
strategies for use over the 
systems’ life, including allocation 
to humans 

SRR: Baseline ConOps 
S/MDR: HSI input to 
ConOps updated from 
previous version 



Analyze expectations to establish 
MOEs for customer satisfaction 

SRR: HSI MOEs captured to 
drive HSI MOPs, TPMs 

2 

Technical 

Requirements 

• Define design and product use 
constraints 

• Define functional and 
behavioral expectation in 
technical terms per 
ConOps/usage 

• Define technical requirements 
in acceptable “shall” 
statements 

SRR: HSI Requirements 
baselined for established 
architecture 

S/MDR: HSI Requirements 
updated for new human 
allocation or changes 



Use MOEs to create MOPs and 
TPMs for HSI success 

S/MDR: HSI MOPs, TPMs 
established for tracking 

3 

Logical 

Decomposition 

Define logical decomposition 
models (e.g., operator tasks) for 
derived requirements and validate 

SRR: Decomposition 
Models, Derived 
Requirements to develop 
lower level design. 

S/MDR: iterate as needed 
for each level of architecture 
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SEE 

Process 

SEE Process Title 

Key HSI Activities 

Major HSI Products 
Per Milestone 



Define and analyze alternative 
design solutions for context of use 
and LCC 

SRR: Identify functions 
allocated to humans and 
update HSI plans 

4 

Design Solution 

Verify/validate the fully defined 
design solution against the 
ConOps 

S/MDR: Iterate for new 
design levels 



Prepare Logistics and Operate-to 
Procedures 

S/MDR: Procedures (draft) 

5 

Product 

Implementation 

Produce early-phase reports, 
mockups, models, prototypes, and 
demonstrators 

SRR, S/MDR: Support 
development of product used 
for human assessments 

6 

Product Integration 

Support production of human- 
centered phase end-items from 
SEE 5 

SRR, S/MDR: Assess 
human element for 
integration 

7 

Product Verification 

Verification of SEE 5 products 

SRR, S/MDR: Verified phase 
product end-items created in 
SEE 5 

8 

Product Validation 

Validation of SEE 5 products, 
Evaluate design solutions against 
ConOps 

SRR, S/MDR: Validated 
phase product end-items 
created in SEE 5 

10 

Technical Planning 

Provide HSI inputs to SEMP (or 
equivalent) and other technical 
plans 

SRR: HSI Planning started 

S/MDR: HSI Plan or 
equivalent (draft) 



Provide HSI inputs to LCC 
estimates 

SRR, S/MDR: LCC 

estimates as needed 

13 

Technical Risk 
Management 

Assess and create mitigation 
plans for HSI Domain risks 

SRR, S/MDR: HSI Domain 
Risks as needed 

17 

Decision Analysis 

Conduct decision analysis 
process for identified technical 
issues including HSI concerns 

SRR, S/MDR: Human- 
centric assessments for 
established architecture 


The key HSI products started in Pre-Phase A are brought to baseline configuration during Phase 
A, as shown in Table 3.1-3, Product Maturity Matrix for Programs and Projects. These products 
are matured by performing the steps as shown in Figure 3.1-1, SEE with HSI Inputs and Outputs. 

Note: The following description of NASA SEE processes is not unique to HSI. 

Stakeholder expectations, SEE 1 , are revisited, validated, and formalized and used to mature the 
ConOps document and create MOEs, which must be established for SRR. 
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These SEE 1 and Pre-Phase A products are then used in the steps for SEE 2, Technical 
Requirements, to create top level requirements. The MOEs are used to create MOPs and TPMs 
as the requirements are matured. Refer to section 4.4.5 for additional information on HSI 
measures. 

Most of the requirements work is completed for the top level architecture by SRR. Additional 
levels of the architecture are then derived from the top level, sometimes with unique milestones. 

Decomposition models are selected and used in SEE 3 to further derive requirements. 
Decomposition models can include human-centric models such as timing diagrams, crew 
timelines, behavior diagrams, and operator task analysis. Critical decisions regarding function 
allocation are made. This may include determinations regarding autonomy and automation as 
well. 

For complex systems, human assessments are performed in SEE 17, Decision Analysis, often per 
technical planning under SEE 10. Process SEE 13, Technical Risk Management, also includes 
probabilistic risk assessment. These cross-cutting processes inform the nine technical processes 
(SEE 10 - 17) and can drive and affect the activities in those processes, especially for HSI, in 
early life cycle phases. 

The HSI requirements and decomposition models are used in SEE 4 to produce the candidate 
design solutions and alternatives. HSI practitioners should engage to analyze the design 
solutions for P/P systems that require extensive human involvement. 

The practitioners should also engage to validate the design solution against the ConOps, as part 
of SEE 8. Any systems that are allocated to humans are identified and the HSI Plan or 
equivalent documentation is updated to reflect the need to address HSI domain considerations for 
those systems. 

HSI practitioners will participate to ensure that early-phase proof of concept and prototype 
products are developed. These products are the output of SEE 5, Product Implementation, and 
take inputs primarily from the SEE 4 and SEE 17. These models and mock-ups can aid in the 
development of requirements and design constraints, and will also provide feedback to SEE 16, 
Technical Assessment process. 

As shown in the Table 3.3-2, HSI practitioners will likely be engaged in the remaining processes 
in the product realization group: Product Verification (SEE 7), Product Validation (SEE 8), and 
Product Integration (SEE 6). These processes are shown in Figure 3.1-1, Systems Engineering 
Engine with HSI Inputs and Outputs. A list of potential human-centered design evaluations and 
products, useful for SEE 7 and SEE 8, can be found in NASA/TP-2014-218556. 

The SRR is the first milestone gate for a review of the requirements, technical plans, and initial 
ConOps document. The TPMs are baselined for SDR, where the candidate design is established 
as the baseline. The simplicity of the products in Table 3.4-2 somewhat masks the significant 
amount of effort and rigor required to complete the activities to produce the products. Complex 
systems can require significant effort to assess options, build mockups, write software models, 
plan future HSI activities, and create documents. 
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It is not practical to detail all of the specific HSI products required for a specific P/P — and, 
indeed, that is the role of the HSI Plan. The number and types of evaluations, mockups, human 
interaction assessments, task and user evaluation, HITL tests, etc. will depend entirely upon the 
nature and scope of the P/P and the fidelity of the evaluation. This is another reason why 
working to develop the HSI plan from the beginning of the P/P is essential. 

3.5 Phase B: Preliminary Design and Technology Completion 

3.5.1 Phase B Objectives 

The key purpose of Phase B is to “define the project in enough detail to establish an initial 
baseline capable of meeting mission needs” (NASA/SP-2007-6105). Within Phase B, if not 
already, requirements will be flowed down from a Level 1 agency collection, to Level 2, 3, and 
possibly other levels as needed by the system and required by any relevant contracts. 


Phase B NASA Systems Engineering Goals 

• Establish a design solution that meets mission needs 

• Establish design dependent requirements and 
interfaces 

• Complete “implementation” level of design 


In Phase B, the work that was completed in Phase A is developed and matured to support 
baselining of the design solution. The processes mature, leading to updates to plans, risk 
assessments, and process documentation prior to the PDR. Phase A system trades, assessments, 
technology selection and solutions are iterated, leading to the concepts, documents, 
requirements, and solutions reaching maturity levels necessary to be reviewed, refined, and 
baselined by the end of the phase. The conclusion of the phase is a selected design solution, 
which is achieved through the PDR. 

Completion of the PDR precedes the KDP C milestone for projects. For programs, PDR 
supports KDP I. Entrance and success criteria of the PDR are provided in NPR 7 123. IB, 
Appendix G, Table G-6. 

HSI practitioners support PDR with HSI-related product submissions and through review of 
design features from an HSI perspective. 

Goals and Success Mapping for HSI in Phase B are provided in Table 3.5-1. 
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Table 3.5-1 Goals and Success Mapping for HSI in Phase B 


Milestone 

HSI Goal 

HSI Success Criteria 


Refine requirements; 
form and validate 
derived Human 
requirements 

The top-level human requirements, including 
mission success criteria, TPMs, and any 
sponsor-imposed constraints are agreed 
upon, finalized, stated clearly, and 
consistent with the preliminary design. 

The flow down of verifiable requirements is 
complete and proper. 

PDR 

Update SEMP, HSI 
Plan, and other 
technical plans 

Definition of the technical interfaces (both 
external entities and between internal 
elements) is consistent with the overall 
technical maturity and provides an 
acceptable level of risk. 

Refine, validate, and 
document technical 
requirements 

The operational concept is technically 
sound, includes human systems, and 
includes the flow down of requirements for 
its execution. 

Technical trade studies are mostly complete 
in sufficient detail and the remaining trade 
studies are identified, plans exist for their 
closure, and potential impacts are 
understood. 


Refine interfaces and 
evaluate compatibility 

Appropriate modeling and analytical results 
are available and have been considered in 
the design. 


3.5.2 Phase B Process and Products 

Since many Phase B activities are continuations or maturations of activities initially begun in 
Phase A, Phase B shares many of the key items for HSI team members to continue supporting. 
However, there is often a greater opportunity for engagement in HITL testing using mockups and 
software simulators, as well as trade studies evaluating various design options. Thus, human 
factors activities have a key role in Phase B, beyond that of requirements definition, getting into 
true design evaluation and maturation. 

A review of the tailoring of the activities performed in Phase B as shown in the wall-chart 
provided with NASA/SP-2007-6105 shows moving from selected and baselined architecture, 
requirements, and solutions in Phase A to a selected design solution in Phase B. 

Processes developed in Phase A continue to be refined, allowing for system design to be 
solidified. Product baselines are iterated and updated, human-system interactions evaluated, and 
trades performed. Table 3.5-2 provides a map to the additional key HSI processes being 
performed in Phase B. Note that the processes executed in the previous phases are still being 
performed iteratively. 
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Table 3.5-2 Process-Product Mapping for HSI in Phase B 


SEE 

Process 

Process Title 

Key HSI Activities 

Major HSI Products per 
Milestone 

2 

Technical 

Requirements 

Define TPMs for human 
performance 

PDR: HSI MOPs refined, TPMs 
defined and tracked 

3 

Logical 

Decomposition 

Refine requirements; form and 
validate derived Human 
requirements 

PDR: Requirements iterated and 
refined for preliminary design; 
ConOps further developed and 
matured 

4 

Design 

Solution 

Prepare for detailed design, 
manufacturing, and testing 

PDR: Support initial development 
of manufacturing, logistics, 
training, and testing plans 

5 

Product 

Implementation 

Produce mockups, models, 
prototypes, and demonstrators 

PDR: Support development of 
products used for human 
assessments 

6 

Product 

Integration 

Ensure solution is compatible with 
integration philosophy 

PDR: Plans/processes for 
integration of lower tier products 

7 

Product 

Verification 

Prepare to conduct verification; 
conduct trial verification for high 
risk items 

PDR: Models and prototypes are 
planned and developed; 

Crew Task Analyses conducted 

8 

Product 

Validation 

Prepare to conduct validation; 
conduct trial verification for high 
risk items; evaluate design against 
ConOps 

PDR: Models and prototypes are 
planned and developed 

10 

Technical 

Planning 

HSI inputs to SEMP, HSI Plan, and 
other technical plans 

PDR: HSI Plan iteration and 
update 

13 

Technical Risk 
Management 

Conduct technical risk 
assessment; implement mitigation 
plans 

PDR: HSI Plan, HSI Domain 
plans, and P/P risk management 
plans 

17 

Decision 

Analysis 

Conduct decision analysis process 
for identified technical issues 
including HSI concerns 

PDR: HSI process feedback 
iterations at each milestone 


The key HSI products started in Phase A are updated during Phase B, as shown in Table 3.1-3, 
Product Maturity Matrix for Programs and Projects. The PDR is the milestone gate for review of 
the requirements, technical plans, interface control documents, and V&V documents. 

HSI practitioner inputs support meeting PDR Entrance Criteria via the HSI Plan, Human Rating 
Certification Package, Verification/Validation Plan, trade-off analyses, and various other 
products. 

SEE 2, Technical Requirements, are refined, along with development of human-related metrics 
to allow for tracking of metrics through the remaining phases. 
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The requirement allocation in SEE 3 produces more detailed requirements and operational 
concepts influenced by the results of Phase A SEE 4 and SEE 5 modeling, prototyping, and 
validation activities. Those activities continue in Phase B, along with preliminary preparation 
for Phase C manufacturing, logistics, training, and testing activities and products. A Preliminary 
hazard analysis ensures that safety requirements have been adequately addressed in system 
design. 

HSI practitioners provide support for many SEE 7 and SEE 8 V&V activities during Phase B, 
providing feedback to system designers, requirements developers, and producers of the various 
PDR products. HITL activities conducted in Phase B can often be “pre-declared” for V&V 
credit, which is typically conducted in Phase D. 

SEE 6, project integration activities, ensures that tiered functionalities are documented and 
communicated between stakeholders at all development levels. Expectations for integration are 
established in support of PDR. SEE 10, SEE 13, and SEE 17 activities also directly support the 
PDR milestone review, as plans, processes, and other products are developed and matured. 

The PDR demonstrates that the preliminary design meets all system requirements with 
acceptable risk and within the cost and schedule constraints and establishes the basis for 
proceeding with detailed design. This is a critical milestone for HSI practitioners, as it is the first 
full review of system design from concept through verification, validation, and operations. The 
positive evidence of HSI influences should be visible through early risk reductions, extensive 
human-system integration, and a mature human-centered design concept. 

3.6 Phase C: Final Design & Fabrication 

3.6.1 Phase C Objectives 

The key purpose of Phase C is to “complete the detailed design of the system (and its associated 
subsystems, including its operations systems), fabricate hardware, and code software” 
(NASA/SP-2007-6105). In essence, this phase occurs when all design details are finalized and 
the system is prepared for testing and verification. 


Phase C NASA Systems Engineering Goals 

• Establish complete, validated detailed design 

• Complete all design specialty audits 

• Establish manufacturability processes and controls 

• Finalize and integrate interfaces 

• Produce items that conform to specs and acceptance criteria 

• Prepare facilities for production 
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In Phase C, the work design solution that was selected in Phase B is prepared for finalization and 
fabrication. The processes mature similarly, further mitigating risks, developing technological 
readiness, optimizing design trades, and proceeding through the milestones. Phase B system 
trades, assessments, technology selection and solutions complete design iterations, leading to the 
start of production of the final design solution by the end of the phase. The conclusion of the 
phase is an end product, which is achieved by working the processes and proceeding through 
the Critical Design Review (CDR), Production Readiness Review (PRR), and System Integration 
Review (SIR). To ensure readiness for production, a PRR and SIR may be held. For many 
projects, the intent of these reviews will be met during the project’s CDR. 

For projects, the CDR, PRR, and SIR support KDP D. For programs, the CDR and SIR support 
KDP II. (See NPR 7120. 5E, section 2.3 for complete details.) 

The Phase C milestone entrance and success criteria are provided in NPR 7123. IB as follows: 

• Table G-7 - CDR for Program 

• Table G-8 - PRR for Project 

• Table G-9 - SIR for Program 


Table 3.6-1 provide Goals and Success Mapping for HSI in Phase C. 

Table 3.6-1 Goals and Success Mapping for HSI in Phase C 


Milestone 

HSI Goal 

HSI Success Criteria 


Verify detailed design 
meets system 
requirements 

Detailed human requirements, verification 
requirements, and integration requirements 
are developed and baselined. 

The flow down of verifiable requirements is 
complete and proper. 

CDR 

Update SEMP, HSI 
Plan, and other 
technical plans 

Definition of the technical interfaces (both 
external entities and between internal 
elements) is consistent with the overall 
technical maturity and provides an 
acceptable level of risk. 


Refine and document 
technical plans 

Technical trade studies are complete to 
sufficient detail and incorporated into 
detailed design. 


Evaluate interface 
compatibility 

Model/prototype components and interfaces. 
Incorporate initial results into detailed 
design. Validate components and interfaces 
against the operational concept. 
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3.6.2 Phase C Process and Products 

Phase C shares many of the key items for HSI team members to continue supporting. In this 
phase, the detailed design is matured based on the results of Phase B HITL testing, simulations, 
and trade studies. Design evaluation and maturation lead to Phase D assembly, integration, and 
test activities. 

A review of the tailoring of the activities performed in Phase C as shown in the wall-chart 
provided with NASA/SP-2007-6105 shows the P/P moving from selected design solution 
architecture, requirements, and solutions in Phase B to an end product in Phase C. 

Processes developed in prior phases continue to be implemented. Product baselines are utilized 
to prepare for production; human-system interactions are evaluated for operations and training 
products; and technological readiness is reevaluated. Table 3.6-2 provides a map to the 
additional key HSI processes being performed in Phase C. 

Table 3.6-2 Process-Product Mapping for HSI in Phase C 


SEE 

Process 

Process Title 

Key HSI Activities 

Major HSI Products per Milestone 

4 

Design Solution 

Mature detailed design, 
manufacturing, and testing 
plans 

CDR/PRR/SIR: Detailed 
manufacturing, logistics, training, 
and testing plans baselined/updated 

5 

Product 

Implementation 

Generate and update detailed 
implementation plans and 
procedures 

CDR/PRR: Finalize design updates 
based on human assessments 
SIR: Integrated HSI inputs evolved 
from individual component inputs 

6 

Product 

Integration 

Review/generate detailed 
integration plans and 
procedures 

CDR/PRR/SIR: Integrated lower 
tiered products 

7 

Product 

Verification 

Conduct verification activities 

CDR/PRR/SIR: Verification results to 
show that system models/prototypes 
satisfy requirements prior to 
production 

8 

Product 

Validation 

Evaluate design against 
ConOps 

CDR/PRR/SIR: Validation results to 
show that system models/prototypes 
satisfy operational intent 

10 

Technical 

Planning 

HSI inputs to SEMP, HSI Plan, 
and other technical plans 

CDR/PRR: HSI Plan iteration and 
update with focus on training and 
operational phases. 

SIR: Integrated HSI inputs evolved 
from individual component inputs 

13 

Technical Risk 
Management 

Conduct technical risk 
assessment; implement 
mitigation plans 

CDR/PRR: HSI Plan, HSI Domain 
plans, and P/P risk management 
plans updated for production and 
operational risks 

SIR: Integrated HSI inputs evolved 
from individual component inputs 
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SEE 

Process 

Process Title 

Key HSI Activities 

Major HSI Products per Milestone 

16 

Technical 

Assessment 

Assess product against plans 
and requirements 

CDR/PRR: Assess detailed design to 
determine suitability prior to 
production 

SIR: Integrated HSI inputs evolved 
from individual component inputs 

17 

Decision 

Analysis 

Conduct decision analysis 
process for identified technical 
issues including HSI concerns 

CDR/PRR/SIR: HSI process 
feedback iterations at each 
milestone 


The key HSI products finalized to prepare for system production during Phase C, as shown in 
Table 3.1-3, HSI Product Maturity. The CDR is the major milestone gate for review of the 
requirements, technical plans, interface control documents, and V&V documents. 

Phase B preliminary V&V activities are continued and matured in Phase C SEE 7 and SEE 8 
activities, establishing a greater level of confidence that the detailed design will meet the 
requirements and operational intent of the system. Models and prototypes are refined as SEE 4 
requirements and SEE 5 plans are generated in support of system CDR. 

Production and operational risks are identified and mitigated through trades and documented in 
support of SEE 13, SEE 16, and SEE17 milestone review preparation. To prepare for Phase D 
system assembly and integration, SEE 10 Technical Planning activities focus on the production 
and operation of the system, making use of knowledge gained from a continued HSI focus on 
design for producibility, safety, maintainability, training, and operation. A hazard analysis 
ensures that safety requirements have been adequately addressed in system design. SEE 6 
project integration activities integrate products from all development tiers in order to support 
development of integrated end-item documentation for CDR. 

The CDR demonstrates that the maturity of the design is appropriate to support proceeding with 
full-scale fabrication, assembly, integration, and test. CDR determines that the technical effort is 
on track to complete the system development, meeting performance requirements within the 
identified cost and schedule constraints. For HSI practitioners, this milestone represents the 
conclusion of the system design and a shift of focus to further improving system operation 
through efficiencies in training, operation planning, and maintenance. The early involvement of 
training, operations, and maintenance personnel in the development of ConOps, requirements, 
and models/prototypes should be very evident as human-system features enable HSI practitioners 
to continue to reduce LCCs by optimizing system interactions rather than trying to fix costly 
design flaws during this phase. 

The positive evidence of HSI influences should be visible through available optimization 
opportunities and reduction of design flaws compared to legacy programs. 
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3.7 Phase D: System Assembly, Integration & Test, Launch 
3.7.1 Phase D Objectives 

The purpose of Phase D is to “assemble, integrate, verify, validate, and launch the system, 
meanwhile developing the confidence that it will be able to meet the systems requirements” 
(NASA/SP-2007-6105). This includes conducting the Test Readiness Review (TRR), the 
System Acceptance Review (SAR), Operational Readiness Review (ORR), and the Flight 
Readiness Review (FRR). These reviews ensure the system is built to required specifications, 
risks have been appropriately mitigated, and that the system is ready for a safe and successful 
mission. Other Phase D activities include updating operational procedures, rehearsals and 
training of operating personnel and crewmembers, and implementation of the logistics and spares 
planning. 


Phase D NASA Systems Engineering Goals 

• Assemble and integrate system 

• Verify and validate system 

• Accept system 

• Integrate pre-launch system 

• Establish readiness to launch/deploy system 


In Phase D, the HSI team is focused on the V&V processes that typically begin after CDR, as the 
end product is integrated for testing. The HSI team has goals to develop the necessary 
verification closure evidence for all HSI requirements and to further reduce mission risk through 
validation of the end product for its intended use as described in the ConOps. HSI goals are also 
to ensure that mission operational products are completed and operators are trained and certified 
for their work during the operations phase. End product system-level and/or flight testing 
typically occur during Phase D, and the HSI team’s goal is to implement the human system 
aspects of flight test planning, execution, data analysis, and reporting. Phase D HSI goals and 
success criteria are mapped to relevant milestones in Table 3.7-1. 

The Phase D milestone entrance and success criteria are provided in NPR 7123. IB as follows: 

• Table G-10 - TRR Entrance and Success Criteria 

• Table G-ll - SAR Entrance and Success Criteria 

• Table G-12 - ORR Entrance and Success Criteria 

• Table G-13 - FRR Entrance and Success Criteria. 
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Table 3.7-1 Goals and Success Mapping for HSI in Phase D 


Milestone 

HSI Goals 

HSI Success Criteria 

TRR 

Complete HSI preparation for and 
endorsement of end product system- 
level/flight test 

Comprehensive HSI input to 
appropriate system-level test 
objectives, requirements, plans 
and procedures 

SAR 

Complete Verification of HSI 
Requirements 

End product system is shown to 
conform to the HSI 
requirements 

Complete End Product Validation 

End product meets the users’ 
needs in the operational 
mission context 

Complete Development of HSI Input 
to Operations Support Products 

Operations support products 
accepted by end users 

ORR/FRR 

Certify the System for Operations 
with Humans 

HSI team’s endorsement of 
system certification, leading to 
operations and sustainment 

Train and Certify the Users for 
Operations with the System 

HSI team’s endorsement of 
user certification, leading to 
operations and sustainment 


3.7.2 Phase D Process and Products 

The V&V activities completed in Phase D are particularly relevant to the HSI Team. The HSI 
requirements are verified based upon the verification statements and rationales written and 
refined from as early as Pre-Phase A. Proper interpretation of these requirements is critical, and 
continuing insight and oversight are needed for the HSI Team to ensure success in this phase. 

Validation of the end product system’s operational effectiveness is also key in this phase. 
Validation events are conducted and reported, and the HSI team is involved in these activities, 
generation and review of the resulting product reports. 

Human-in-the-loop (HITL) activities conducted in earlier phases that were “pre-declared” for 
verification credit are now assessed for closing requirements. The HSI Team ensures that these 
HITL activities are consistent with the “test the way we fly” or “test as you fly” principle 
described in NASA/SP-2007-6105, in order to use them for verification closures. 

The HSI team engages in the system-level test/flight test planning, execution, data analysis, and 
reporting. The team provides HSI input to appropriate system-level test objectives, requirements, 
plans and procedures, and test reports. Test data necessary to validate HSI analytical models is 
collected and used in model correlation. 

The HSI Team supports users of the system in completion of their pre-deployment training. 

HSI practitioners will be called upon to engage in activities as shown in Table 3.7-2, Process- 
Product Mapping for HSI in Phase D. 
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Table 3.7-2 Process-Product Mapping for HSI in Phase D 


SEE 

Process 

SEE Process Title 

Key HSI Activities 

Major HSI Products Per 
Milestone 

6 

Product Integration 

Support system integration as 
appropriate 

TRR: HSI input to system-level 
test plans 

7 

Product Verification 

Conduct verification of the 
human system requirements 

SAR: Requirement verification 
closure reports from HITL 
test/demonstration and from HSI 
inspections and analyses 

8 

Product Validation 

Complete validation events 
that demonstrate the end 
product meets user needs in 
accordance with the ConOps 

TRR: HSI input to system-level 
test plans/flight test plans 

SAR: Product validation reports 
from HITL test/demonstration 
and from HSI inspections and 
analyses 

SAR: System-level test and/or 
flight test reports that provide 
validation of the end product and 
provide data for validation of 
analytical models used to predict 
system performance 

9 

Product Transition 

Provide HSI input to the 
technical reviews that support 
transition of the end product 
to its intended user for 
operations 

SAR: HSI inputs to operations 
and maintenance manuals, 
procedures, and training 
packages 

SAR: HSI inputs to system 
design data books and other 
supporting technical materials for 
use during Phase E 

SAR: Validated HSI analytical 
models of the end product 
system 

Generate HSI objective 
evidence of the acceptability 
of the end product and its 
operational mission 

ORR/FRR: HSI inputs to the 
system certification package 
(e.g. Human Rating Certification 
Package) 

13 

Technical Risk 
Management 

Conduct technical risk 
assessment; implement 
mitigation plans 

ORR/FRR: HSI inputs to P/P risk 
management plans updated with 
all prelaunch mitigations 
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HSI system development products are finalized during Phase D, as shown in Table 3.1-3, 

Product Maturity Matrix for Programs and Projects. These products are matured by performing 
the steps as shown in Figure 3.1-1, Systems Engineering Engine with HSI Inputs and Outputs, 
for SEE 6, SEE 7, SEE 8, SEE 9 and SEE 13. 

The TRR ensures P/P readiness for a major system-level test, such as a space system flight test. 
HSI input to the preparation and planning for this test is part of the TRR package. 

The SAR provides for acceptance of the end product system by the operational P/P user. HSI 
input to the SAR package includes complete V&V reporting on HSI aspects of requirements and 
operational concepts. It also includes validated analytical models provided by HSI domain 
experts, and HSI input to operational support products such as training documentation, and 
manuals and procedures for operation and maintenance of the end product system. 

The ORR/FRR are the milestones for defining P/P readiness to move into Phase E operations. 
HSI products include objective evidence of the acceptability of all human system aspects of the 
end product in its operational mission context. This evidence informs the system certification 
package (e.g., Human Rating Certification Package), which will be the focus of the Agency and 
its TAs as they endorse the end product readiness for transition to user operations. 

3.8 Phase E: Operations and Sustainment 

3.8.1 Phase E Objectives 

The Operations & Sustainment Phase, Phase E, is focused upon conducting the mission, meeting 
the initially identified need, and maintaining support for that need. The HSI team role in Phase E 
focuses on identifying which aspects of the as-built system are operationally successful and 
which are not. HSI lessons learned are generated from a variety of sources including: 

• Inflight testing and demonstration of HSI aspects of the mission/system 

• User/crew debriefs and interviews 

• Collection of human system data (e.g., errors, losses of efficiency, incidents, accidents) 

• Collection of human performance data (e.g., crew time / task time) 

• Collection of physiologic indicators (e.g., consumables usage, vital signs, illness/injury 
rates) 

• Mission data and reports. 

These sources of information should be carefully reviewed and synthesized, lessons learned 
captured, and HSI findings documented in reports or publications for the ongoing operations and 
to benefit future P/P. 

The health and safety of all ground and flight personnel are critical criteria for evaluating the 
success of the operations and sustainment phase of the P/P. The HSI team is key to maintaining 
personnel health and safety, leading directly to successful human performance in mission 
operations, which enables the success of the overall P/P through its operational phase. 
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Phase E NASA Systems Engineering Goals 

• Perform mission 

• Sustain system 

• Improve/augment system 


In Phase E, the HSI team is focused on observing the HSI aspects of the operating system and its 
users/maintainers to ensure human safety, health, and performance in operations. The HSI team 
aims to document and communicate specific aspects of operations that need improvement to 
achieve P/P mission success and human safety, health, and performance objectives. A 
complementary goal is to document those aspects of the mission-system that are fully successful 
due to HSI effort during development. 

Phase E HSI goals and success criteria are mapped to the relevant milestones in Table 3.8-1. 

The Post-Launch Assessment Review (PLAR) evaluates the readiness of the spacecraft systems 
to proceed with full, routine operations after post-launch deployment. The review also evaluates 
the status of the project plans and the capability to conduct the mission with emphasis on near- 
term operations and mission-critical events. The HSI team supports the PLAR with an 
evaluation of human- system aspects of the operational system’s readiness to proceed into full 
operations. 


Table 3.8-1 Goals and Success Mapping for HSI in Phase E 


Milestone 

HSI Goals 

HSI Success Criteria 

PLAR, 

CERR, 

PFAR 

Ensure user/maintainer safety, 
health, and performance 

Safe and productive operations 
of the system to accomplish the 
defined mission 

PLAR, 

CERR, 

PFAR 

Identify mission-system anomalies 
and operational aspects that need 
improvement in relation to users and 
maintainers 

Documented lessons learned 
are provided to the P/P for 
implementation of necessary 
corrections and improvements 

PLAR, 

CERR, 

PFAR 

Identify mission-system operational 
aspects that are fully successful in 
relation to users and maintainers, 
with linkage to HSI effort during the 
P/P development phases 

Documented lessons learned 
are provided to the P/P to 
demonstrate an operational 
return on HSI investment made 
during system development 

DR 

Capture HSI knowledge gained over 
the course of the P/P 

HSI knowledge is placed into 
the P/P documentation system 
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The Critical Events Readiness Review (CERR) evaluates the readiness of the project and the 
flight system to execute a critical event during flight operation. The HSI team provides inputs to 
CERR, for example, the human-system readiness to perform an extravehicular activity (EVA). 

The Post-Flight Assessment Review (PFAR) evaluates how well mission objectives were met 
during a mission, identifies all flight and ground system anomalies that occurred during the 
flight, and determines the actions necessary to mitigate or resolve the anomalies for future flights 
of the same spacecraft design. The HSI team describes the success of human-system mission 
objectives, lessons learned from the flight, and improvements needed for further operations of 
the system. 

The Decommissioning Review (DR) confirms the decision to terminate or decommission the 
system and assesses the readiness of the system for the safe decommissioning and disposal of 
system assets. The HSI team may have additional lessons learned from the final stages of the 
mission, and final values for TPMs evaluated during the operational phase. 

The Phase E milestone entrance and success criteria are provided in NPR 7 123. IB as follows: 

• Table G-14 - PLAR Entrance and Success Criteria 

• Table G-15 - CERR Entrance and Success Criteria 

• Table G-16 - PFAR Entrance and Success Criteria. 


3.8.2 Phase E Process and Products 

Specific HSI team activities in this phase include sustaining engineering of the mission system 
while it is being operated, operational monitoring, data collection on the safety, health, and 
performance of the humans involved with the mission system, and documentation of new HSI 
knowledge generated during this phase. The HSI team produces technical analyses on potential 
operational improvements and on successful operational outcomes due to HSI effort performed 
during system development. For operational flight testing, the HSI team produces reports on 
Flight Test Objective outcomes that may validate the integrated end product or contribute to the 
validation of analytical models of the system. As part of HSI sustaining effort, the team 
evaluates upgraded operational methods and system features as alternate solutions for issues 
emerging during the mission. Appendix C.2 provides an example of sustaining lessons learned 
for Shuttle. Examples of crew time as a key measure is cited throughout this document, as well. 

Table 3.8-2 defines HSI products resulting from these activities. 
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Table 3.8-2 Process-Product Mapping for HSI in Phase E 


SEE 

Process 

SEE Process Title 

Key HSI Activities 

Major HSI Products Per 
Milestone 

2 

Technical 

Requirements 

HSI team evaluates final values of 
HSI TPMs 

DR: HSI TPM Final Report 

8 

Product Validation 

Analyze Flight Test Objective data 
and report on the outcome 

PFAR: HSI input to Flight 
Test Reports 

PFAR: HSI models 
validated based on flight 
data 

15 

Technical Data 
Management 

HSI Team produces HSI 
Technical Lessons Learned 

DR: HSI Lessons Learned 

16 

Technical 

Assessment 

Analyze operational aspects that 
affect human users/maintainers to 
determine where the system is 
fully successful or needs 
improvement 

PLAR, CERR, PFAR: HSI 

lessons learned and 
technical reports on human- 
system operations 


The Phase E milestones ensure user/maintainer safety, health, and performance, and capture HSI 
knowledge gained over the course of the P/P. 

HSI system operational procedures are validated and documented for SEE 8 and assessed for 
optimization for SEE 16. The P/P is also assessed for satisfactory completion of design 
objectives. TPM results (SEE 2), HSI validations, and design/operational feedback being 
captured documented and captured as lessons learned for SEE 15. 

3.9 Phase F: Closeout 

3.9.1 Phase F Objectives 

The Closeout Phase, Phase F, is the final phase of the NASA SE process or life cycle. The role 
of the HSI team in Phase F is similar to that of Phase E, primarily ensuring that lessons learned 
are collected and fed forward into future P/P. These lessons may impact the revision and 
development of future requirements or standards. They may suggest new design opportunities or 
reveal previously unquantified limitations of systems or their operators. There may be data that 
has been catalogued throughout a design’s operational missions that were to this point 
unreleased, and now is a key opportunity for the HSI team to review this information. 


Phase F NASA Systems Engineering Goals 

• Implement decommission/disposal 

• Analysis of data 

• Analysis of returned samples 


3-31 



HSI Practitioner's Guide 


In Phase F, the HSI team is focused on achieving the safe and successful decommissioning and 
disposal of the mission system, while documenting the knowledge gained in its development and 
operations. Successful decommissioning of the system is the end state for the P/P. 

Phase F HSI goals and success criteria are mapped to relevant the milestones in Table 3.9-1. 

The Phase F milestone entrance and success criteria are provided in NPR 7 123. IB as follows: 

• Table G-18 - Disposal Readiness Review Entrance and Success Criteria. 


Table 3.9-1 Goals and Success Mapping for HSI in Phase F 


Milestone 

HSI Goals 

HSI Success Criteria 

Disposal 
Readiness 
Review (DRR) 

Provide HSI support to the safe and 
successful decommissioning of the 
system. 

Capture final HSI Technical Lessons 
Learned. 

Archiving HSI data from P/P. 

HSI aspects of system 
decommissioning and disposal 
are incorporated into the P/P 
plan. 

HSI data and lessons learned 
are captured for archiving. 


3.9.2 Phase F Process and Products 

The HSI team supports the system decommissioning and disposal process, where human 
operations and interactions with hardware/software continue to be essential to the achievement of 
P/P goals. The HSI team closes out its P/P work by documenting information that characterizes 
the value added by HSI to the P/P, and by transmitting this information to P/P and institutional 
organizations for archiving and re-use on future P/P. 

HSI continues to provide uniquely valuable products during this final phase, by retrospective 
analysis of the P/P results and through HSI input to the human-system aspects of the 
decommissioning process itself. 

Table 3.9-2 defines HSI products resulting from these activities. The Disposal Readiness 
Review (DRR) confirms the readiness for the final disposal of the system assets. At this time, 
the HSI team may provide human-system inputs to the decommissioning and disposal planning. 
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Table 3.9-2 Process-Product Mapping for HSI in Phase F 


SEE 

Process 

SEE Process Title 

Key HSI Activities 

Major HSI Products Per 
Milestone 

N/A 

N/A 

HSI team provides input to the 
system decommissioning plan 

DRR: HSI input to the 
decommissioning and 
disposal plan 


The Phase F continues the Phase E system documentation activities. This phase may also overlap 
with early-phase activities for follow-on system designs that mature, replace, further optimize, or 
extend developed system capabilities. 
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4.0 HSI PLANNING AND EXECUTION 

The planning and execution of HSI is ultimately the responsibility of the P/P manager, but is 
carried out through the P/P’s SE process, led by delegated practitioners skilled in HSI. The 
systems engineer is skilled in the art and science of balancing organizational and technical 
interactions in complex systems but may not have experience in human-centered design or in 
HSI disciplines. Gathering together the appropriate human-centered domain and subject matter 
experts is essential for project success in HSI. Since the entire P/P team is involved in 
implementing the SE approach, everyone should recognize some responsibility for aspects of 
HSI’s planning and execution to ensure P/P success. The HSI practitioner must communicate 
effectively with the entire P/P team in order to generate the necessary level of HSI engagement. 
To support that outcome, this section provides an in-depth look at skills and management 
approaches required to execute HSI processes and produce HSI products. 

4.1 NASA HSI Products 

As evident in section 3, tangible products from the HSI effort are necessary for communication 
and engagement with the P/P. Three guiding documents are the ConOps, SEMP, and the HSI 
Plan. Other HSI products may also be documented in the HSI Plan. Not all P/Ps will have the 
same set of products. 

The ConOps is developed early in Pre-Phase A, describes the high-level concept of how the 
system will be used to meet stakeholder expectations, usually in a time- sequenced manner. It 
describes the system from an operational perspective and helps facilitate an understanding of the 
system goals. The ConOps is essential for human integration, as it defines the operational, 
maintenance, transport, and other user interactions that HSI domain stakeholders will have with 
the system. Section 4.4.2, Developing a Concept of Operations (ConOps), provides information 
useful for composing the ConOps to address HSI considerations. 

The SEMP is the primary, top-level technical management document for a P/P. It is developed 
early in the life cycle, and is updated at significant milestones throughout the P/P life cycle. 

The HSI Plan — a practice in NPR 7123.1B, is a clearly identified section within the SEMP or a 
stand-alone HSI Plan document, depending on the size and scope of the P/P. In order to manage 
HSI throughout the life cycle of a program, a comprehensive HSI Plan or HSI portion of the 
SEMP should include strategies to address issues related to the development of HSI 
requirements. A detailed discussion of the HSI Plan content is provided in section 4.4.1, Writing 
the HSI Plan. 

HSI requirements are an important HSI product. Requirements are the ultimate tool for 
impacting system design and performance, but they often also have cost and schedule 
implications. HSI requirements ensure that the human is adequately considered during system 
design. HSI requirements are developed, integrated, interpreted, and verified with support from 
parties responsible for HSI, from SE personnel, and from discipline experts in each HSI domain. 
Development considerations for HSI requirements are covered in section 4.4.4 of this document. 

A P/P’s HSI approach should be tailored to include use of various products and tools as 
appropriate. Note, however, that HSI data is often integrated with other data in a standard 
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product of the P/P and not uniquely an HSI product. Any product can have HSI implications; 
human considerations naturally occur as part of effective capability-based SE. 

Section 4.2, Scaling and Tailoring HSI to Program/Project Size, provides HSI product guidance 
for various P/P sizes. 

Sections 4.3 through 4.6 of this guide provide additional detail on the key HSI products listed in 
this section and more (e.g., planning, tailoring for size, metrics). The text also covers a variety 
of important HSI products resulting from human-centered trade-offs, usability assessments, and 
training programs. These products are put into the context of the NASA Life Cycle in Chapter 3. 

4.2 Scaling and Tailoring HSI to Program/Project Size 

Tailoring of the size and scope of the overall program management and SE efforts for a 
particular P/P will be performed by the program management and SE team leads. The HSI effort 
required of a project should be similarly scaled and tailored to fit a P/P’s size, budget, mission, 
and scope. The HSI practitioner should work with the program management and SE teams to 
scope the HSI effort, and the HSI practitioner should strongly advocate for approval of an HSI 
level of effort that will successfully serve the P/P’s outcomes. 

An initial focus of tailoring HSI to P/P size is to determine whether a full or abbreviated HSI 
Plan is needed. Also, the HSI practitioner should work with the program management and SE 
teams to determine if the HSI Plan will be a standalone document or contained within the SEMP. 
These HSI Plan determinations are based on assessing factors such as a) the extent to which 
humans are involved with the system under development, b) the size of the P/P, c) the project 
category (per NPR 7120.5E, section 2.1.4), and e) P/P mission scope. If a P/P involves 
significant HSI, user/maintainer training, or new human-centered technology, for example, then 
a full HSI Plan should be initiated. In a smaller P/P or one that is similar to a predecessor system 
in the aforementioned respects, then an abbreviated HSI section within the SEMP may be 
sufficient as the HSI Plan. The HSI practitioner is cautioned against using the P/P budget as a 
primary consideration when determining HSI effort. 

A checklist examining the P/P needs across all the HSI domains can assist the HSI practitioner to 
appropriately set the scale and content of the HSI effort. A sample checklist is provided in this 
guide as Appendix B, Sample HSI Implementation Planning Checklist. As soon as the HSI 
practitioner assumes HSI lead responsibility for a system’s development and acquisition, the 
checklist assessment should be initiated and documented in the HSI planning effort. 

A simplified, notional list of P/P size characteristics is shown in Table 4.2-1, which can be used 
by the Practitioner to scale the HSI effort along the lines of the example activities and products 
shown in Table 4.2-2. These tables and their illustrated characteristics are intended as useful 
indicators, not requirements. It is not essential that all of the characteristics for P/P size be met 
to assign an overall size category. Generally, the HSI effort for a P/P should be sized and 
focused based on its most critical safety or human involvement characteristic(s). 
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Table 4.2-1 Characteristics of Program/Project Relevant to HSI Scaling 


P/P Size 

Human Safety 

Human Involvement 

Large-Scale HSI 
Effort 

Category 1 

• Significant Risk 

• Hazards Controlled, 
Monitored by humans 

• LOC/LOM risks 
managed 

• Human-rated Program 

• Life-sustaining 
equipment 

• Large and complex hardware/software 
systems 

• Tight coupling of human actions to 
critical system performance 

• Flight Crew involved with day-to-day 
operations; “lives in the product” 

• Ground crew, operators critical to 
success 

• Extensive training required 

Medium-Scale HSI 
Effort 

Category II 

• Modest risk, hazard 
controls 

• Supports Human-rated 
Program 

• Medium system complexity with a 
number of hardware/software 
subsystems 

• Moderate coupling of human actions to 
critical system performance 

• Crew essential to mission success; 
“works with the product” 

• Ground crew, operators essential to 
success; some automation (Robotics 
program) 

Small-Scale HSI 
Effort 

Category III 

• Low risk, hazards 

• Supports Human-rated 
Program 

• Simple systems with small number of 
hardware/software components 

• Loose coupling of human actions to 
critical system performance 

• Crew involved with some aspects; “uses 
the product” 

• Ground crew, operators less involved; 
automation use to reduce human 
interactions 

• Some training required 
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Table 4.2-2 HSI Plan Activity and Product Tailoring 


Product or Activity 

Large-Scale HSI 
Effort 

Medium-Scale HSI 
Effort 

Small-Scale HSI 
Effort 

Early Planning 

ConOps 

Standalone Doc(s) 

Possible Standalone 
Doc 

Part of Project Docs 

HSI Plan 

Standalone Doc 

Part of SEMP 

Part of Project Docs 

HSI Team 

Required* 

Recommended 

As needed 

Design Planning 

HSI Requirements 

Standalone Doc 

Strong Effort 

Modest Effort 

Human-centered design 

Significant Effort 

Strong Effort 

Modest Effort 

Human-in-the-Loop 
Prototyping, Evaluation 

Significant Effort, 
Iterative 

Strong Effort 

Modest Effort 

Production and Operation 

Human-in-the-Loop 
Verification, Training 

Required 

Supported 

Desireable 

Validation Activities 

Supported 

Supported 

Desireable 

Operational Monitoring 

Supported 

Supported 

As needed 

Lessons Learned 

Supported 

Supported 

Desireable 


* NPR 8705. 2B controls formation of the HSI Team 


HSI at the End Item Level 

HSI approaches can also be applied to individual end items (e.g., exercise equipment, tools) 
using the guidance in this section. Device size is irrelevant; human interaction is the key. 

The effort may be highly constrained for limited resources when scaled to this level, but the 
HSI key concepts still apply: “human considerations” are fundamental to HSI, no matter how 
big (or small) the project. Crew time is a highly constrained resource and each device can 
have a significant impact: consider both local (device) and global (system) interactions. 


It should be noted that a P/P will often produce a system that contains within it lower level 
components, units, or elements that are less human-oriented and so may be treated with less 
attention to HSI techniques. For example, a structural component not exposed to human 
interaction may have very few HSI requirements that drive its design. The HSI team, including 
all its domains, should be involved in this assessment of what is important for the HSI effort to 
cover and at what depth. A role of the HSI Plan is to identify those areas where HSI techniques 
are required and to document the approaches to be taken. 
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4.3 Planning the HSI Effort 

HSI planning begins at the earliest outset of a project/P — i.e., during (or even before) Pre-Phase 
A. Besides learning about the goals and intent of the P/P, the HSI practitioner should begin 
focusing on putting in place the people, plans, processes, metrics, and products that will yield life 
cycle benefits to the particular program or project. These HSI preparations are documented in 
the HSI Plan. Section 4.1, NASA HSI Products, describes how the HSI Plan relates to other HSI 
products and section 4.4.1, Writing the HSI Plan, provides guidance on writing the Plan. 

4.3.1 Developing the Plan 

The practitioner should plan NASA-led HSI activities, requirements, and team structure, as well 
as understand the role that any prime contractor engaged on the program or project will perform, 
particularly in terms of HSI and HSI deliverables. A clear vision of HSI efforts needed to 
support the particulars of the P/P is critical to developing a comprehensive, integrated HSI 
approach, delivering a return on HSI investment, and producing a system that will meet user 
needs from human-systems and operations standpoint. 

4.3.2 Organizing the HSI Team 

The HSI practitioner should assess the types of human-oriented system design expertise needed 
and plan to form a team that is appropriately composed and organized to fulfill the HSI plans, 
activities, and products necessary for the particular P/P’s life cycle. Composition of the team is 
determined by the scope, nature of the system and its operational mission, and the types of 
human/system design challenges anticipated. The lead HSI practitioner is the person the P/P 
management identifies to lead the HSI effort and report to program management and SE process 
managers. This lead HSI practitioner assists P/P management in assessing HSI personnel needs, 
HSI personnel timing, and critical early-phase HSI efforts, based on the P/P’s scale, mission, 
budget, and scope. The HSI lead for the P/P plans and negotiates the necessary institutional 
SME resources as early as practical in order for the HSI team to form and create an 
implementation plan prior to early-phase activities, such as requirements definition, system 
architecture development, and functional decomposition. The HSI Plan captures appropriate HSI 
team information, intra- and inter-team roles and responsibilities, staffing agreements, and HSI 
team objectives. 

For programs or projects that require large scale HSI efforts, extensive institutional resources are 
dedicated to HSI. A comprehensive, knowledgeable HSI team is essential to mission success, 
particularly in large scale P/Ps. For small-scale HSI efforts, identifying the scope of the HSI 
effort is equally as critical since the smaller HSI team size requires precise planning of a 
resource-constrained SME skill set. Understanding the domain expertise required for a particular 
program or project allows the practitioner to sharply focus the available HSI resources on the 
most critical HSI efforts documented in the HSI Plan. 

4.3.3 Balancing Institutional Goals with Programmatic Goals 

HSI work is closely associated with NASA’s need to develop and operate systems in affordable 
and cost-effective ways, while also controlling safety and mission success risks to acceptable 
levels that are appropriate to each application. 
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Program authorities such as NASA mission directorates are chartered to create capabilities and to 
conduct missions, and they accomplish this via their funded programs and projects. They are 
motivated to take on additional risk at times in system development and operation in order to 
maximize programmatic accomplishments. The institutional authorities — i.e., Agency technical 
authorities — are charged with evaluating the risk posture of each program and project in order to 
ensure that the degree of risk to safety and mission success is well understood and is 
appropriately balanced against the need to accomplish the programmatic goals. This healthy 
tension is inherent to NASA’s governance model. 

The HSI practitioner should recognize that while working within the P/P, the HSI team also is 
closely associated with technical authority stakeholders from the NASA institution. For 
example, the HMTA promulgates human system standards at the Agency level (NASA-STD- 
3001) that are applicable to human space flight programs and projects. More broadly, the SMA 
TA and ETA provide standards applicable to all Agency programs and projects. The HSI effort 
creates one of the balance points between institutional standards and programmatic goals, as 
illustrated by the Constellation Program (CxP) example below. 


Human Systems Integration in Practice: Constellation Lessons Learned 

NASA’s Constellation program (CxP) provided a unique test bed for Human Systems 
Integration (HSI) as a fundamental element of the Systems Engineering (SE) process. 
Constellation was the first major program to have HSI mandated by NASA’s Human Rating 
document. The CxP Human Systems Integration Group (HSIG) was a part of the Systems 
Engineering and Integration (SE&I) organization within the program office, and existed 
alongside similar groups such as Flight Performance, Environments & Constraints, and 
Integrated Loads, Structures and Mechanisms. Although the HSIG successfully managed, 
via influence leadership, a down-and-in Community of Practice to facilitate technical 
integration and issue resolution, the program structure did not provide the necessary top- 
down authority to drive integrated design. Involvement of and coordination with NASA 
Technical Authorities was a key aspect of the HSIG in development of a human-rated system 
design. 
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4.3.4 Identifying Human-Centered Trade-offs 

Instituting HSI requirements in system development and acquisition programs lead to the 
inclusion of human-centered considerations in trade studies and trade-off evaluations. There are 
a variety of measures that can be employed to set up an effective trade-off that directly or 
indirectly affects cost. But other equally valuable criteria can be established per the goals of the 
P/P that are not cost-based, but values-based. 

The benefit to a P/P of implementing HSI is based on the value subscribed by the stakeholders. 
If the stakeholders place a high value on a design that reduces operational costs and optimizes 
human efficiency, then the engineering team can establish criteria to drive the trade space. 
Reducing cost, in and of itself, is not always the top priority, but must be considered along with 
the other selected criteria. 

The criteria will be tailored to the needs of the individual P/P trade-off, which can be performed 
at a system, element, unit, or component level as needed. 

The primary purpose of this section is to encourage a wider range of criteria be considered when 
setting up the trade study or trade-off matrix. A few examples are provided in Table 4.3-1, 
Example HSI Trade Study Criteria, and Table 4.3-2, HSI Trade-Off Examples. 


Table 4.3-1 Example HSI Trade Study Criteria 


Trade Study 

Example Criteria 

Crew-operated Instrument 
or Medical Device (multiple 
sources) 

• Portability: attach points, handles, size, cabling 

• Power: battery management logistics, cabling, heat, noise (fans), 
interface availability and type 

• Calibration: crew time, periodicity, complexity, accuracy 

• Complexity to operate (subjective assessment) 

• Display readability 

Net Habitable Volume 
(multiple designs) 

• Proposed Crew size > consumables, life support, etc. 

• Proposed Design Reference Mission (DRM) timeline 

• Vehicle size constraints 


4-7 


HSI Practitioner's Guide 


Table 4.3-2 HSI Trade-Off Examples 


Example Topic 

T rade-Off 

Considerations (HSI) 

Hand-held Device 

Portability: attached power 
cable vs. replaceable 
batteries 

• Battery Logistics cost 

• Crew time impact for replacing batteries 

• Battery run time 

Line/Orbital 
Replacement Unit 
(LRU/ORU) 

Testability: built-in 
diagnostic self-test vs. 
ready spare on-orbit 

• Mass, power, complexity, comm, for 
added capability 

• MTBF; R&R periodicity 

• MTTR; R&R on-orbit time 

• Criticality of function 

Emergency Egress and 
post-landing survival in 
sea states 

Cabin temperature vs. 
acoustic noise vs. suit and 
vehicle design vs. crew 
health and performance 

• Vehicle constraints: battery life, 
communications, life support 

• Landing ConOps 

• Human Health constraints 

Water Sampling Device 
Complexity 

Crew time vs. cost of 
automated or autonomous 
system 

• Cost of design 

• Crew time impact for repetitious 
operation 

• Design for back-up manual mode 


For further examples, refer to the report “Human Systems Integration (HSI) Case Studies from 
the NASA Constellation Program” by Baggerman, Berdich, and Whitmore (2009). 

For decision-making, establishing an exact cost is not as important as having a measurable 
metric that translates to cost. In this approach, the true cost is not actually calculated, but a cost- 
related metric is derived to “stand in” for cost. The cost-equivalent metric is used in evaluations 
or even requirements to produce desired outcomes in decision-making and design options. An 
example cost-equivalent metric can be found in section 4.4.5, Developing and Using HSI 
Metrics. 

Another prime consideration for decision making is for the larger architecture-level trade-offs 
which can have a significant impact on LCC. These decisions must be made early in the project 
life cycle and validated with the other P/P stakeholder values, goals, and objectives. The range 
of choices is extensive but can include “moving the sliders” for such things as: 

• Function allocation to hardware, software, and humans 

• Autonomy 

• Automation 

• Redundancy, fault management architecture 

• Engineering development tool choice (model-based, etc.) 

• Risk tolerance for new technologies 

• Operational environments and envelopes 
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The high-level architecture and programmatic decisions must take into account the level of 
involvement of humans in the system. Refer to NASA/SP-2010-576, NASA Risk-Informed 
Decision Making Handbook, for more details. 

Some specific examples include crew time for select phases (set up, operation, tear down, 
maintenance), number of ground operator or hours, ease of access, ease of repair, ease of 
disposal, etc. These parameters are sometimes used for a comparative cost analysis in a trade-off 
study or as a “killer trade.” 

Table 4.3-3 provides additional examples from each of the HSI domains. 

Table 4.3-3 Cost-equivalent Criteria Examples for Decision Making 


Criteria 

Domain 

Criteria Type 

Units of Measure 

Approach involves handling of hazardous 
material (yes or no?) 

Safety 

Go-No Go 

N/A 

Mean time to “turn around” crew capsule 
for next flight 

Maintainability 

and 

Supportability 

Weighted 

Days 

(Incompressible) 

Acoustic Noise (generated by item) 

Habitability and 
Environment 

Weighted 

dB 

Tool operation (task analysis) with range 
of motion constraints 

Human Factors 
Engineering 

Weighted 

Workload Score 

Quantity of user steps to execute a given 
activity 

Operations 

Resource 

Weighted 

Steps or Person- 
Hours 

Amount of training required for mastering 
a task (trainers plus crew time) 

Training 

Weighted 

Person-Hours 


LCC and trade studies are just two examples of HSI measures used in P/P designs. An additional 
discussion on HSI metrics can be found in section 4.4.5, Developing and Using HSI Metrics. 

A case study overview from ISS is provided for additional emphasis. 
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Emergency Lighting Case Study 

During ISS development, a requirement for emergency lighting was established, intended to 
provide module exit “pathway” illumination during a power outage. The original fielded 
solution, Emergency Egress Lighting System (EELS), failed to take into account the 
extensive crew time required to change out the batteries required to keep the system 
operational. Plus there was extensive logistics for flying up batteries. After many “lost” 
crew hours, ISS reconsidered, and a second design iteration produced a much more elegant, 
low-cost and low-impact solution: circular photo-luminescent (glow-in-the-dark) markers, 
the Emergency Egress Guidance System (EEGS). 

In this case study, crew man-hours is used as a cost-equivalent measure. The potential 
solutions in the second, “experience informed” iteration considered the actual monetary cost 
of the battery logistics as well. All of the potential design solutions were compared to each 
other using both the cost-equivalent crew man-hours and the actual cost logistics metric. The 
selected solution is low-cost for both metrics. 


4.3.5 HSI Focus on Commercial-Off-The-Shelf (COTS) Products 

The Design Solution process (SEE #4) or trade studies performed as part of the Decision 
Analysis process (SEE #17) may identify potential Commercial-off-the-Shelf (COTS) solutions 
that are viable candidates to meet the need. 

A increasing trend within P/P is the use of COTS hardware or software when possible in order to 
save cost and meet schedule. Though the use of COTS products can save time and money, 
COTS products also increase the need for HSI assessment and risk mitigation. Competing 
COTS products may initially appear functionally equal, but an HSI practitioner may identify 
significant differences or provide important selection criteria. 

The initial HSI screening during COTS search is critical to identifying a product that will 
integrate into the flight mission and system. Besides the requisite form, fit, and function criteria, 
the selection criteria can include other HSI domain-related factors such as (as applicable): 

• Vendor reputation and experience 

• Product history and consumer reviews 

• Replacement availability, second source options 

• Product life cycle (time on market, time to obsolescence) 

• Manufacturing process and materials 

• Complexity of device or application 

• Standards-based design 
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• Risk to cost and schedule 

• Safety to crew, vehicle, and mission 

• User interfaces 

• Impact to crew task time and efficiency 

• Workmanship concerns 

• Preliminary environmental assessment (e.g., thermal, vibe, power) 

• Suitability for function from HSI perspective 


There are many factors in assessing “suitability” for operation of COTS equipment in space. 

Since COTS devices are designed and built for terrestrial applications, the engineer making the 
selection must often resort to comparative assessments between candidates, discussed in earlier 
sections, with prioritized criteria. There are complex questions that must be answered with the 
support of experienced domain experts and stakeholders. Since the COTS product is already 
designed, the features and functions may not be a “perfect match” for the new space application. 
For example: Is it better to have a unit with additional features beyond functional need, or one 
that meets needs and is simple to operate? Will/can the unit be operated by a suited 
crewmember? Are the power, data, and physical interfaces suitable for the intended environment 
and workspace? Is the device labeled properly? Are special tools required to service the item, if 
required? An evaluation checklist should be developed that includes HSI criteria for each trade 
study /trade-off being conducted. 

From a human safety perspective, engineer is advised to “look inside” the article to ensure proper 
workmanship and no prohibited parts or materials. Early testing of the COTS item is also 
advised in order to ensure expected function, quality, and protection of the project schedule if 
something goes awry. The engineer is strongly advised to work with domain experts and check 
“the rules” of the certifying authority for use of COTS on the P/P. All COTS items should be 
identified in design reviews and design documentation to allow visibility to regulating authorities 
(e.g., NASA Center Chief Engineer Office, electrical, electronic, and electromechanical [EEE] 
parts team). It is also recommended to consider developing a risk to the project for use of COTS. 

4.3.6 Implementing HSI in Incremental Development 

HSI Practitioners may be tasked to apply HSI goals to life cycle processes that have been tailored 
to the considerations of a specific P/P. In many cases, the outcome will be an incremental 
development model that produces the system’s initial capability early, followed by iterative 
cycles of feature development and product refinement. HSI is traditionally iterative in nature, as 
a key practice is the establishment and maintenance of communication and feedback loops 
between designers and HSI domain stakeholders. 

In an incremental development environment (e.g., Agile software development), phases may be 
distinct or may overlap. They may also be plan-driven from a mature set of initial requirements, 
experience-driven based on experiences gained from interaction with the initial capability 
system, or a combinations of both. The goal of incremental development is to decompose the 
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development effort into smaller, manageable, and deliverable development of useful and high- 
quality products. By developing in increments, the systems gain maturity through continuous 
integration, validation, and verification, and development teams gain flexibility through early 
identification of risks and defects, and early incorporation of end-user feedback. 

To balance HSI’s objectives of early stakeholder engagement and focus on human-centered 
design with the flexibility and fluidity of an incremental design approach, practitioners and teams 
are required to be cohesive, communicative, and committed to meeting customer expectations. 

An iterative design may use swift-moving processes, but the primary focus is ultimately to 
design the system that the customer needs within the P/P constraints. NASA projects require 
rigorous attention to safety as a design consideration essential to mission success. Successful 
incremental design environments within NASA have tailored design processes to the NASA 
culture, creating hybrid life cycle models that combine elements of incremental development 
with more traditional, plan-based development to provide customers visibility into design 
considerations for safety, operability, and cost effectiveness. 

In addition to processes for developing high quality systems, system usability processes are 
essential for ensuring stakeholder buy-in and mission success. Usability analyses and usability 
SMEs help mature early stage system functionalities into later stage design optimizations. This 
allows methods based on producing early hardware/software components to integrate the human 
during the complete development effort while consistently influencing design refinements 
throughout the life cycle. 

Appendix C.6 provides an example of a successful implementation of an incremental design 
method (Agile) within the context of a NASA program. 

4.4 HSI Approach Execution 

Implementation of an HSI approach requires development of various products, which guide the 
execution of the approach. Key skills to effectively implement HSI are integration of subject 
matter expertise and development of HSI products including ConOps, HSI Plan/SEMP, and HSI- 
based requirements. Early HSI efforts are leveraged in assessing training needs and usability. In 
addition, an effective approach utilizes metrics and lessons learned to gauge effectiveness and 
provide insight to future HSI implementations. 

Throughout this guide, we describe how the HSI practitioner engages with the program/project to 
develop the HSI products, bring in experts for specific tasks, and support the entire life cycle. 
This comprehensive approach ensures that HSI is inherent in SE activities. The HSI practitioner 
is also a key participant in reviews (e.g., CDR) in order to detect problems hidden in a complex 
design. This is only accomplished by being immersively engaged with the development effort. 

4.4.1 Writing the HSI Plan 

The HSI Plan (HSIP in NPR 7 123. IB) documents a systematic approach for applying HSI 
concepts to optimize total system performance (hardware, software, and human), operational 
effectiveness, and suitability, survivability, safety, and affordability. Depending on the scale and 
complexity of the HSI effort, the HSI Plan is captured as a part of project documentation, as a 
section within the SEMP, or as a stand-alone HSI Plan document (see section 4.2). In order to 
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manage HSI throughout the life cycle of a program, the HSI Plan should include a detailed 
approach for incorporating the human requirements into all aspects of system development, 
training, operation, maintenance, and support. 

The HSI Plan is written by HSI personnel to address issues resulting from HSI assessments of 
predecessor systems and/or previous system spirals and increments. The HSI Plan gives insight 
into points of HSI engagement and the associated effectiveness measures. The HSI Plan exists to 
document sound, human-centered development approaches from the human/system functional 
analyses performed during pre-planning activities through product verification and operations 
assessments. An outline of the HSI Plan is provided below. For more details, see Appendix A, 
HSI Plan Content Outline. Table 4.4-1, Guidelines for Development and Refinement of the HSI 
Plan, provides by-phase details on producing and maturing the HSI Plan. 


HSI Plan Content Outline 

1 .0 Introduction 

1.1 Purpose 

1.2 Scope 

1.3 Definitions 

2.0 Applicable Documents 

3.0 HSI Objectives 

3.1 System Description 

3.2 HSI Relevance 

4.0 HSI Strategy 

4.1 HSI Strategy Summary 

4.2 HSI Domains 

5.0 HSI Requirements, Organization, and Risk Management 

5.1 HSI Requirements 

5.2 HSI Organization, Roles, and Responsibilities 

5.2.1 HSI Organization 

5.2.2 HSI Roles & Responsibilities 

5.3 HSI Issue and Risk Processing 

6.0 HSI Implementation 

6.1 HSI Implementation Summary 

6.2 HSI Activities and Products 

6.3 HSI Plan Update 
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Table 4.4-1 Guidelines for Development and Refinement of the HSI Plan 


Life Cycle 
Phase 

Guidelines for Development and Refinement of the HSI Plan 

Pre-Phase 
A Phase A 

Develop the HSI Plan based on the results of functional analyses and derived human- 
centered requirements. 

Phase B 

Revise HSI Plan to reflect results of human, hardware, and software task allocation 
determination, system specifications, and source selection strategies and results. 

Phase C 

Identify potential human-related shortfalls and failures in human-system integration. 
Develop and execute mitigation strategies. Update HSI Plan to include latest system 
specifications, integration strategy, analyses of training and support requirements. 

Phase D 

Update HSI Plan to address issues related to system integration with training and 
support strategies. After evaluation, incorporate results of evaluations regarding 
usability, operability, and supportability of the system. Ensure testing is accomplished 
by operational users in operating conditions. Identify human-related shortfalls and 
failures in human-machine integration. After the Plan is updated, document lessons 
learned to prepare for the next iteration of design. 

Phase E 
Phase F 

These phases realize the execution of plans derived during the development and 
acquisition of the system (e.g., training plan, disposal plan, operational resources, 
survivability, etc.). This is another opportunity to collect data (e.g., habitability, 
usability, training, environment, safety, occupational health issues, etc.) and document 
lessons learned. 


The HSI Plan will define and emphasize the HSI approach in each of the domains. By 
identifying areas of SME need, the HSI team captures rationale to size SME engagement and 
expertise to provide system optimization insight tailored to the specific P/P needs. It is 
particularly important for the HSI Plan to capture an understanding of roles and responsibilities, 
not only within the HSI team, but also for the HSI team’s overall interaction with the larger 
program management and SE teams and with other (hardware/software) discipline teams. The 
HSI Plan outlines the discipline’s approach to risk identification and mitigation and how the HSI 
team will integrate with and/or utilize the program’s risk and mitigation processes. 

A checklist can assist the HSI practitioner to plan and assemble the HSI effort. The HSI team 
can utilize the checklist to assist in the HSI planning and documentation. The checklist will lead 
the HSI team through identifying baselines for, and integration of, HSI domains. A sample 
checklist is provided in Appendix B. Sample HSI Implementation Planning Checklist. As soon 
as the HSI practitioner assumes responsibility for a system development and acquisition 
program, the checklist should be initiated and documented in the HSI Plan. 

4.4.2 Developing a Concept of Operations (ConOps) 

The ConOps document is an essential tool for all P/P and not just an HSI consideration. The 
ConOps document (or possibly multiple documents for a large program) provides guidance for 
development of the system; function allocations to hardware, software, and humans; stakeholder 
goals and “requirements,” and much more. The document is a view of the system from the 
perspective of the user(s). The amount of architecture or “design solution” included in the 
ConOps is a matter of approach but is generally kept minimal so as not to limit creative design 
solutions. 
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The ConOps is also used to establish a standard to which the P/P can be “trued” by means of 
validation activities. The well-known SE “V” diagram must begin with the ConOps on the left 
side and ends with the validation of the entire system on the top right. 

The guidance that the ConOps provides for the development of the architecture and plans dictate 
that the ConOps be created early in the P/P life cycle, starting in Pre-Phase A, and baselined in 
Phase A. The document is updated for major reviews and changes will impact many P/P 
documents. 

Due to the inclusive nature and wide scope of the ConOps, inputs must be collected from a range 
of sources and experienced SMEs. Effort should be taken to hold reviews and disposition 
comments from relevant team members and stakeholders. Often the same personnel who create 
the ConOps document will become the HSI team, if required to be stood up per the Human 
Rating requirements document. 

Function allocation is performed early in the develop life cycle, often in conjunction with the 
ConOps development activity. Table 4.4-2, Function Allocation Process, provides details on the 
process and some specific HSI activities to be conducted. 

Table 4.4-2 Function Allocation Process 


Function allocation Process 

HSI Mapping for Resilience 

Successively define what the system must do at 
lower levels 

Ensure that lower-level definitions include the 
human functions 

Translate high-level performance requirements 
into detailed performance criteria or constraints to 
define how well the system must perform 

Include human performance requirements and 
constraints (e.g., operator workload and 
availability) relative to mission performance 

Identify and define internal and external 
functional interfaces 

Define adaptive user interface and system 
feedback and control requirements to optimize 
operator workload, provide context, status, time, 
and priority 

Identify functional groupings to minimize 
redundancy 

Resilient systems may include redundant 
functions - ensure functions are coordinated 

Determine functional characteristics of existing 
components 

Evaluate existing components in new contexts 
under a range of operating conditions 

Perform trade studies to determine alternative 
functional approaches to meet requirements 

Examine trade-offs with various levels of 
automation, and consider other HSI domains 


(Ref: The Human Role in Resilience Engineering: Malleable Function Allocation, Matthew R. Risserfor 
NDIA, October 2012). 
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4.4.3 Integration of Subject Matter Expertise for HSI Activities 

Consideration of SMEs is a critical part of the early definition (e.g., ConOps) and design process 
(e.g., requirements and analyses). Table 1.6-1 lists the domain areas for HSI that will provide 
the needed skill base. Table 1.6-1 provides a sample listing of many areas of specific HSI 
expertise available from SMEs. The HSI practitioner holds the key to leveraging the depth of 
their knowledge and skills, by methodical integration across multiple HSI domains, using 
established SE techniques and additional techniques that are more specific to the HSI team. 

The SMEs efforts include development of HSI requirements for the program or project, 
application of those requirements to the system, and involvement in verification of the system as 
meeting the requirements. Depending on the nature of the P/P, the SMEs also may engage in 
product development, evaluation, and validation efforts, including planning and execution of 
integrated system tests, demonstrations, analyses, and ultimately, system operations. 

Note that much of the SE-related human integration work has typically been performed by 
personnel who are SMEs in human factors engineering (HFE), they have learned to apply broad 
mission-system models that capture many aspects of HSI. These models are consistent with 
general SE and are applied by a skilled HSI practitioner. 

The HSI practitioner’s and team’s integration effort lends appropriate, balanced weight to all 
SME inputs, without neglecting those that may be very specialized or that are more difficult to 
incorporate into design or operational methods, as illustrated in the example below. 


Subject Matter Expertise Collaboration Example 

Knowledge about human deconditioning after extended exposure to weightlessness is 

very specialized, and is the subject of multiple lines of research to improve the scientific and 
medical evidence base. Knowledge in this area is continually improving, and SMEs are the 
primary source of the most current insights. 

An HSI practitioner may actively consult with SMEs in the Sensorimotor, Musculoskeletal, 
Cardiovascular, and HFE areas in order to provide a comprehensive, integrated view of 
deconditioning as a design influence on crew tasking at the time of spacecraft landing. This 
would provide the HSI practitioner with implications for the vehicle’s design, to ensure crew 
health and safety risk was mitigated to the appropriate level to meet NASA human system 
standards. 
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4.4.4 Developing HSI-based Requirements 

HSI Requirements are the ultimate tool for impacting system design and performance, but they 
often also have cost and schedule implications. HSI requirements ensure that the human is 
adequately considered during system design. HSI requirements are developed, integrated, 
interpreted, and verified with support from parties responsible for HSI, from SE personnel, and 
from discipline experts in each HSI domain. HSI requirements may come from standards, but 
they also are derived from the ConOps via functional analysis of the mission, scope, relevant 
HSI domains, and human risk mitigation. 

Per NPR 8705.2B for Human Space Flight (HSF) P/P, the NASA-STD-3001 Vol. 1 and Vol. 2 
standards provide the primary basis for HSI requirements, to mitigate health and performance 
risks to levels that are acceptable to the Agency. Additional standards including FAA-HF-STD- 
001, Human Factors Assessments in Investment Analysis: Definition & Process Summary for 
Cost, Risk, and Benefit, and MIF-STD-1472D, Human Engineering Design Criteria for Military 
Systems, Equipment, and Facilities, are applied in selected areas for human rating purposes and 
can be used for non-HSF P/P such as planetary robotic missions. For all space flight P/P, 
NASA-STD-5005D, Standard for the Design and Fabrication of Ground Support Equipment, 
provides the human integration standards for Ground Support Equipment (GSE). Additional 
standards from engineering domains, such as JSC-08080-2A, JSC Design and Procedural 
Standards, and from the safety domain, such as NASA-STD 8709.20, Management of Safety and 
Mission Assurance Technical Authority (SMA TA) Requirements, are related to the integrated 
set of HSI requirements. An example of a standard for software requirements for aviation is 
RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, 
and the companion documents. 

Significant HSI guidance can come from other documents, such as institutional functionality and 
requirements to support each human space flight program. One such document is the Medical 
Operations Requirements Document (MORD), which is derived from NASA-STD-3001 Volume 
1. Similarly, a Human Systems Integration Requirements (HSIR) document is derived from 
NASA-STD-3001 Volume 2. The HSI Practitioner must seek out the applicable document(s) for 
the program being supported. The documents mentioned generically above are typical for a 
human space flight program. 

Each standard statement essentially defines a level of acceptable risk in a specific area. The 
standards are translated into program HSI requirements managed by the HSI team, to ensure 
traceability back to Agency standards, while creating information usable by the P/P in the SE, 
design, and operations teams. These requirements are sometimes very specific and quantitative 
because of the constraints imposed by human capabilities and limitations (e.g., specifics of 
maintaining health, performance), but they allow as much design/operations trade space as 
practical while protecting the human. 

The HSI practitioner leads the effort to apply relevant Agency standards to the P/P, based on the 
DRMs and system architecture. 
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Developing HSI-based Requirements 

As an example, for the Exploration Systems Development programs, the Human System 
Integration Requirements (HSIR) document was developed per the process outlined in this 
section. For the Commercial Crew Program (CCP) the HSI requirements were embedded 
into the CCT-REQ-1 130 requirements document, per the program’s desire to have an 
integrated set of all program-level requirements. In each case, the program DRMs were used 
to translate from Agency standards to requirements that were relevant to the program- specific 
system architectures. 


4.4.5 Developing and Using HSI Metrics 

HSI practitioners use metrics to estimate and track the effectiveness of the HSI implementation. 
Using quantitative metrics whenever possible allows HSI requirements to become measurable, 
which is necessary for effective implementation within the SE life cycle. To be effective, HSI 
metrics must be objective and verifiable, and further, must be validated against the system goals. 
Effective metrics can also reveal trends and identify where trade studies are needed. 

Cost, schedule, risk, and performance are vital categories of metrics for characterizing success of 
HSI efforts. As noted earlier in this guide, key metrics that often measure HSI’s success (or 
failure) on a program/project are operational resources (numbers of humans needed to make a 
system operational), personnel skill levels, and training. 

Program- specific metrics may be developed to track elements of system development that have 
high levels of management visibility because they pose significant risk to budget, schedule, or 
mission success. These metrics are defined and tracked in the HSI Plan for reporting of program 
cost and value during system design reviews. The metrics in the HSI Plan mature during the 
project life cycle, improving the significance and merit of the metrics and showing trends in 
relation to program goals over time. 

Depending on the nature of the program risk area, an HSI practitioner characterizes the risk using 
one or more of a variety of measurement methodologies. NASA/SP-2007-6105, section 7.8, 
details how (MOPs and MOEs can be used to establish and manage technical margins, thereby 
reducing development risk and increasing the probability of mission success. Similarly, a 
program may define programmatic and technical leading indicators (TLIs) to ensure proper 
progress and management. Definition, trending, and tracking of TLIs is detailed in NASA/SP- 
2014-3705, NASA Space Flight Program and Project Management Handbook. 

Key Performance Parameters (KPPs) are metrics derived from overarching program goals, and 
are, therefore, applied to a particular scope. It is important to outline the goals and scope that 
will be served by a HSI KPP within the context of NASA in order to understand the life cycle 
impacts of HSI. 
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Key Performance Parameters (KPPs) 

An example of a KPP that can be applied to space systems is crew time. One of the most 
challenging parts of defining a crew time KPP is in determining the threshold and objective 
values. ISS crew has had to go 30 days without a day off to accommodate necessary tasks; 
therefore, the objective value should be conservative to protect for unplanned activities 
(particularly safety critical activities) and maintain crew psychological health. The threshold 
value should likewise show significant improvement over the current ISS paradigm. If the 
baseline were to assume 2.5 out of 6 or 7 crewmembers’ time would be devoted to 
maintenance, that yields the following: 

Crew time required threshold value: No more than 40% of the crew work day hours should 
be devoted to task preparation, scheduled and preventative maintenance, training and 
procedure review, and check-out of on-orbit hardware and software systems. The objective 
value is set at 35%. Crew work day hours are defined assuming the standards regarding 
personal time, exercise, and sleep remain the same independent of the mission duration or 
destination, and is exclusive of the abovementioned activities. 

An Astronaut’s Experience on Mir: 

“. . .1 learned that it is impossible to separate habitability issues from productivity in scientific 
research. They’re one and the same — from food, toilets, and a good layout of work station 
space.” 

- David Wolf, Space News, 22, March 16-22, 1998. 


Consistent with this approach, a KPP could also apply to ground-based mission controllers as 
well as ground-based maintenance and logistics activities, expressed as a percentage of the 
human portion of the cycle time in mission control or in turn-around and launch preparation 
activities. These attributes are essential for providing the required program capabilities and 
contributing to improvement, effectiveness, achievability, and affordability as part of HSI SE 
activities. 

4.4.6 HSI Verification and Validation 

The HSI team focuses on achievement of functionally effective, maintainable systems that 
conform to the applicable human capabilities and constraints for each P/P. The success of the 
overall HSI effort relies on the HSI practitioner to prove that the end product meets the system 
design goals. 
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To verify that the system design meets the defined HSI requirements and validate that the system 
design meets the functional capabilities defined in the ConOps, the HSI practitioner uses a 
combination of human centered testing, modeling, and analysis. The design methods listed in 
section 2.5, HSI Team Application of Tools, Models, and Analyses, may be reapplied during the 
verification and validation (V&V) phases of the life cycle to prove that the design process has 
produced an appropriate end product. System verification requirements should also be written to 
include appropriate HSI-related evaluations. 

Beyond verifying that system requirements have been satisfied, validation from an HSI 
perspective will focus on system optimization and risk mitigation. Optimally usable systems 
result from successful management of system integration with human components. Early testing 
and evaluation helps to mitigate functional risks by validating appropriate system functionality. 

The scope of V&V activities largely depends on the nature of the DRM and system architecture. 
The relevant human characteristics may drive many aspects of human-to-system interface V&V 
(e.g., hardware and software interfaces). In a small-scale, simple project, the HSI requirements 
may focus on specific features of a hardware device that involve human visual interface (e.g., 
labeling or information displays) or manual interaction (e.g., switches and controls). In more 
complex P/P, this may extend to driving the nature of function allocations among many humans, 
hardware end items, and software configuration items. For a human space flight P/P, where a 
flight crew is dependent on system functionality to maintain their lives during a space flight 
mission, the HSI requirements will also drive complex system capabilities such as environmental 
control, life support, and habitation. 

In each case, the system functionality must be characterized by the HSI team in the context of the 
overall P/P mission-system design. In some cases, functional optimization may be characterized 
by usability, determined as a likelihood of user errors when interacting with the system 
hardware/software or by assessing user satisfaction with the system. The outcome of successful 
HSI V&V efforts will be a system that is verified to meet system requirements, while validating 
that the design also conforms to the user needs in the context of the P/P mission (i.e., DRMs) as 
defined in the ConOps. Through HSI, the resulting end product system architecture mitigates 
user risk (i.e., human safety, health, and performance risk) to an acceptable level. 

A key resource for achieving human certification of a spacecraft is NASA/TP-2014-218556. It 
is also a good reference for the many structured activities and products for human-centered 
design, in general. 
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HSI Example: Orion Usability 

Human interfaces to modern complex systems typically include extensive 
software-driven displays and controls. HSI methods are critically 
important to produce safe and effective system operations through these 
software interfaces. In the Orion human space flight development 
program, a team of HSI personnel, focused in the HFE domain, performed 
dedicated analysis, standards development, HITL evaluations, and design 
refinement of many software display formats that will be used by flight 
crew to operate the Orion spacecraft. This activity demonstrated the value 
of HSI personnel as essential members of an early-stage, collaborative 
team including astronauts as primary users, software and avionics 
developers, and rapid prototyping experts. The products of this effort 
informed Orion software design work beginning in the pre-PDR stage of 
the program. 


4.4.7 Training Domain Program Development 

Knowledge derived from testing and evaluating usability can be extremely helpful in the 
development of system training. Often training plans are only considered after designs have 
been completed and are fixed. Considering training during earlier concept phases would make 
training more effective, as well as would ensure that designs selected during trade-off analyses 
have been evaluated to assess their impact on training. For example, will a particular design 
require specialized skills, unique methods, or repeated training sessions? The HSI team can 
boost training considerations early by including training resources in early assessments and 
providing the results of early functional analysis such as human task allocations and usability 
evaluations. These analyses may be provided to training groups for maturation and use in formal 
training. 

HSI Plan documentation of the training approach should address training concepts and strategy 
in areas appropriate to the system. Training areas such as equipment familiarity, facilities, 
simulations, training aids, use of virtual systems, required skills, task time constraints, and 
system access constraints are likely to apply to space systems. 

An effective training program will address many of the following criteria: 

• Allow for interactions between platforms through simulation and virtual exercises, and 
provide training realism to include a realistic environment, communications, and 
associated integrated systems. 

• Embedded training capabilities that do not degrade system performance below threshold 
values nor degrade the maintainability or component life of the system. 
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• An embedded performance measurement capability to support immediate feedback to the 
operators/maintainers and possibly to serve as a readiness measure for the training 
personnel. 

• Training logistics necessary to support the training concept (e.g., requirements for new or 
upgrades to existing training facilities). 

• Provide concurrent capability with actual equipment and training devices and systems. 

4.4.8 Capturing Lessons Learned for Future HSI Activities 

As a NASA discipline, HSI should strategically strive to identify consistent KPPs that may 
become common HSI currency across program/project types. Doing this will not only help 
clarify basic duties required of the HSI practitioner and of a successful HSI engagement, but 
having consistent metrics will help build a database that could demonstrate HSI’s return on 
investment and that could help build a database of lessons learned for the practice of HSI. 

Large and successful programs and/or projects typically become long-lived with extended 
operations phase(s), often with modifications performed to systems to extend original objectives 
and systems life, add new capabilities or mission objectives, and accommodate for unexpected 
behaviors. Extensive systems upgrades or refurbishment often start the SE process back at an 
early life cycle phase, usually Pre-Phase A. And, of course, the startup of any entirely new 
program or project begins at Pre-Phase A. The HSI practitioner can use the HSI Plan to 
document specific HSI goals that are based on lessons learned to ensure those goals are given 
their proper significance to influence design. 

An important piece of information to bring to any Pre-Phase A (or other early phase in the life 
cycle) is lessons learned from the operation of the original system or, in the case of new starts, 
the operation of similar, legacy systems. The lessons learned capture system may be provided as 
an institutional resource or as a knowledge capture system provided for all program/projects by a 
NASA center. If a relevant lessons learned system is not able to inform a program/project, the 
management team must endeavor to perform a literature search to identify applicable lessons 
learned, a time-consuming and often unsatisfying process. 

Having an active knowledge-capture system running during the operational phases of NASA 
systems requires resources, strategic thinking, and persistence. Additionally, to enhance its 
usefulness, an ongoing lessons learned capture system should have guidance available to 
facilitate its use by new designers who may not be aware which lessons are best suited to apply. 

As a best practice, engineers should invest time to query any available program/project 
knowledge capture systems for lessons learned applicable to their design challenge. Since it is 
impractical to leam “everything,” engineers are by default obliged to rely on specialists and 
experts to avoid the pitfalls and capitalize on previous successful implementations. 
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Capturing Lessons Learned for Future HSI Activities 

“Only a fool learns from his own mistakes. The wise man learns from the 
mistakes of others.” 

— Otto von Bismarck 


For HSI practitioners, strategically investing in and utilizing knowledge capture systems carries 
unique challenges given the large volume of previous work that must be leveraged in order to 
“insert” humans into space system design. However, it should always be remembered that unlike 
other systems, the HSI practitioner does not have the option to “redesign” the human to fit the 
system, but must understand the intricacies of building a product for designed interaction of the 
human element with every aspect of the system throughout its life cycle. 


Crew Comment Database 

The ISS Program has implemented a Crew Comment Database, which 
can be searched for helpful comments from crew regarding a specific tread, 
device, procedure, etc. The reports from this database are a good source 
for lessons learned for new designs, or for the “extended Ops” phase where 
changes need to be made to the existing hardware to meet new mission 
objectives. ( Contact the ISS Program Office at JSC.) 


4.4.9 Life Cycle Cost Effect of HSI 

As previously stated, a primary goal of HSI is to reduce overall P/P cost. HSI practitioners use 
the tools and techniques described in this guide not only for effective human-system design but 
also for cost avoidance in areas of HSI. Though overall system safety, effectiveness, and 
efficiency are goals of the HSI process, it was the potential for LCC savings that led to HSI 
becoming mandatory in the U. S. DoD and other federal agencies. 

The NASA HSI practitioner should keep the cost avoidance aspect of HSI in view as the ultimate 
human element discipline integrator who must translate design decisions into P/P common 
currencies such as LCC, down time required for maintenance procedures, total system autonomy 
from logistics and resupply, etc. Human element life cycle operations generally manifest 
themselves as numbers of people, specialized skillsets, and the resources needed for training all 
users, maintainers, and operators. 

It is not within the scope of this guide to provide a “how to” for calculating cost for P/P, but the 
effect of HSI on costs of established processes and P/P decision-making is important to consider. 
NASA/SP-2014-3705 is an excellent resource for P/P cost management guidance. See sections 
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5.5, Maturing, Approving, and Maintaining Program and Project Plans, Baselines, and 
Commitments, and 5.6, Cost and Schedule Analysis Work to Support Decisions, in the handbook. 
NASA/SP-2014-3705 also refers to the NASA Cost Estimating Handbook at 
http://www.nasa.gov/offices/ooe/CAD/nasa-cost-estimating-handbook-ceh/ . 

See “Cost Estimation of HSI” (Kevin Liu, 2010) for specific guidance including using the 
Constructive Systems Engineering Model (COSYSMO) tool. 

From an HSI investment standpoint, the users of NASA hardware and software expect products 
that can be used safely and effectively to accomplish a given mission, with minimal errors and 
maximum efficiency. They also expect that the development community has addressed user 
needs and capacities as intrinsic to system effectiveness. These expectations may not be realized 
without a unified and integrated HSI investment. 

As a P/P progresses through its life cycle, the cost of making design changes increases 
dramatically. (See Figure 1.4-2, Life Cycle Cost with Overlay showing “Locked-in” Costs, and 
the discussion in section 1.4 of this guide.) Future costs are “locked in” early in the course of 
decision-making; therefore, alternate design concepts should be iteratively evaluated for their 
LCC impact or failure to find more effective alternatives. Growth in operations phase personnel 
costs is particularly possible and even probable if not evaluated early. System designers must 
not assume that any design solution can be made usable by adding personnel, skills, and training. 
Rather, system designers must assume that these human resource assets are as limited as any 
other P/P asset. Costs can also increase from making assumptions about human performance 
that are not achievable or from not including HSI domain considerations in design trade analyses 
to appropriately bound out-year cost escalation in operations, maintenance, and logistics human 
element expenditures. Applying HSI processes should reduce LCC through emphasizing 
efficient human performance goals and operations during system design and development. 

There are not many case studies that fully evaluate the impact of HSI to LCC on past programs 
or that fully evaluate the return on investment of applying HSI fully and effectively. This is 
because it is rare that the outcome of a program that implemented HSI can be compared to the 
outcome of an identical program that did not, thereby producing a controlled comparison. The 
true cost of a path not taken is difficult, if not impossible, to obtain. However, adding HSI- 
oriented alternatives to the SE hardware/software trade space can provide another means to 
positively impact and evaluate LCC through the SE trade study process. This is covered in detail 
in section 4.3.4, Identifying Human-centered Trade-offs. 

Particularly in the earliest stages of a new P/P, the HSI practitioner may find it necessary to 
justify the value of providing targets for and tracking costs for the human elements required to 
make a system functional throughout its life cycle. Standing on requirements documents alone 
may not carry as much leverage as being able to cite examples and case studies where HSI 
makes (or could have made) a difference in the success (or failure) of a P/P to meet its 
stakeholders’ expectations. Some examples of both positive and negative HSI case studies are 
provided in section 4.4.10. 
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4.4.10 HSI Case Studies 

Appendix C is structured to provide several case studies, moving from negative examples in 
which P/P did not fully leverage HSI, to their detriment, to positive examples in which P/P 
implemented HSI to their benefit. The final case is of a future ideal state for a human Mars 
program. The following cases are cited in the appendix: 

• C.l - F-22 Hypoxia-Like Incidents: HSI Experience 

• C.2 - Shuttle Ground Processing: HSI Experience 

• C. 3 - F- 119 Engine: HSI Experience 

• C.4 - Constellation Program: HSI Experience 

• C.5 - HSI Ideal State for Future Large Scale Human Space Flight Program 

• C.6 - Agile Development Brings New Challenges for Software Assurance at NASA 
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APPENDIX A HSI PLAN CONTENT OUTLINE 


A.1 HSI Plan Overview 

The Human Systems Integration (HSI) Plan documents the strategy for and planned 
implementation of HSI through a particular program’s or project’s (P/P’s) life cycle. The intent 
of HSI is: 

• To ensure the human elements of the total system are effectively integrated with 
hardware and software elements, 

• To ensure all human capital required to develop and operate the system is accounted for 
in life cycle costing, and 

• To ensure that the system is built to accommodate the characteristics of the user 
population that will operate, maintain, and support the system. 

The HSI Plan is program- or project-specific and is a NASA Systems Engineering (SE) 
applicable document per NASA Procedural Requirements (NPR) 7 123. IB, NASA Systems 
Engineering Processes and Requirements. The HSI Plan should address: 

• Roles and responsibilities for integration across HSI domains, 

• Roles and responsibilities for coordinating integrated HSI domain inputs with the 
Program team and stakeholders, 

• HSI goals and deliverables for each phase of the life cycle, 

• Entry and exit criteria with defined metrics for each phase, review, and milestone, 

• Planned methods, tools, requirements, processes and standards for conducting HSI, 

• Strategies for identifying and resolving HSI risks, and 

• Alignment strategy with the System Engineering Management Plan (SEMP). 

The party or parties responsible for P/P HSI implementation — e.g., an HSI practitioner (or 
team) — should be identified by the P/P manager. The HSI practitioner or team develops and 
maintains the HSI Plan with support from and coordination with the project manager and system 
engineer. 

Implementation of HSI on a P/P utilizes many of the tools and products already required by 
SE — e.g., development of a Concept of Operations (ConOps), clear function allocation across the 
elements of a system (hardware, software, and human), and the use of key performance 
measurements through the life cycle to validate and verify HSI’s effectiveness. It is not the 
intent of the HSI Plan or its implementation to duplicate other SE plans or processes, but rather 
to define the unique HSI effort being taken to ensure the human element is given equal 
consideration to hardware/software elements of a P/P. 
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A.2 HSI Plan Content Outline 

Each P/P-specific HSI Plan should be tailored to fit the P/P’s size, scope, and purpose. The 
following is a sample outline for a major program — e.g., space flight or aeronautics: 

1.0 Introduction 

1.1 Purpose 

This section briefly identifies the ultimate objectives for this P/P’s HSI Plan. This section also 
introduces the intended implementers and users of this HSI Plan. 

1.2 Scope 

This section describes the overall scope of the HSI Plan ’s role in documenting the strategy for 
and implementation of HSI. Overall, this section describes that the HSI Plan: 

• Is a dynamic document that will be updated at key life cycle milestones. 

• Is a planning and management guide that describes how HSI will be relevant to the P/P ’s 
goals. 

• Describes planned HSI methodology, tools, schedules, and deliverables. 

• Identifies known P/P HSI issues and concerns and explains how their resolutions will be 
addressed. 

• Defines P/P HSI organizational elements, roles and responsibilities. 

• May serx’e as an audit trail that documents HSI data sources, analyses, activities, trade 
studies, and decisions not captured in other P/P documentation. 

1.3 Definitions 

This section defines key HSI terms and references relevant P/P-specific terms. 

2.0 Applicable Documents 

This section lists all documents, references, and data sources that are invoked by HSI’s 
implementation on the P/P, that have a direct impact on HSI outcomes, and/or are impacted by 
the HSI effort. 

3.0 HSI Objectives 

3.1 System Description 

This section describes the system, missions to be performed, expected operational 
environments ), predecessor and/or legacy systems (and lessons learned), capability gaps, stage 
of development, etc. Additionally, reference should be made to the acquisition strategy for the 
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system — e.g., if it is developed in-house within NASA or if major systems are intended for 
external procurement. The overall strategy for program integration should be referenced. 

Note that this information is likely captured in other P/P documentation and can be referenced 
in the PISI Plan rather than repeated. 

3.2 HSI Relevance 

At a high level, this section describes HSI’s relevance to the P/P — i. e. , how the HSI strategy will 
improve the P/P ’s outcome. Known HSI challenges should be described along with mention of 
areas where human performance in the system ’s operations is predicted to directly impact the 
probability of overall system performance and mission success. 

HSI Relevance 

Key points: 

• Describe performance characteristics of the human elements known to be 
key drivers to a desired total system performance outcome. 

• Describe the total system performance goals that require HSI support. 

• Identify HSI concerns with legacy systems — e.g., if operations and logistics, 
work force, skill selection, required training, logistics support, operators’ 
time, maintenance, and/or risks to safety and success exceeded expectations. 

• Identify potential cost, schedule, risk, and trade-off concerns with the 
integration of human elements — i.e., quantity and skills of operators, 
maintainers, ground controllers, etc. 


4.0 HSI Strategy 

4.1 HSI Strategy Summary 

This section summarizes the HSI approaches, planning, management and strategies for the P/P. 
It should describe how HSI products will be integrated across all HSI domains and how HSI 
inputs to P/P SE and management processes contribute to system performance and help contain 
life cycle cost (LCC). This section (or Implementation Summary, section 6 of this outline) should 
include a top level schedule showing key HSI milestones. 
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HSI Strategy 


Key points: 

• Identify critical program-/project-specific HSI key decision points that will be 
used to track HSI implementation and success. 

• Identify key enabling (and particularly, emerging) technologies and 
methodologies that may be overlooked in hardware/software systems trade 
studies but that may positively contribute to HSI implementation — e.g., in the 
areas of human performance, workload, personnel management, training, 
safety, and survivability. 

• Describe HSI products that will be integrated with program/project systems 
engineering (SE) products, analyses, risks, trade studies, and activities. 

• Describe efforts to ensure HSI will contribute in critically important Phase A 
and Pre-Phase A cost-effective design concept studies. 

• Describe the plan and schedule for updating the HSI Plan through the 
program/project life cycle. 


4.2 HSI Domains 

This section identifies the HSI domains (see Table 1.6-1, “NASA HSI Domains, ” of this 
Handbook ) applicable to the P/P including rationale for their relevance. 


HSI Domains 

Key points: 

• Identify any domain(s) associated with human performance capabilities and 
limitations whose integration into the program/project is likely to directly 
affect the probability of successful program/project outcome. 

• An overview of processes to apply, document, validate, evaluate, and mitigate 
HSI domain knowledge and to integrate domain knowledge into integrated 
HSI inputs to program/project and systems engineering processes. 
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5.0 HSI Requirements, Organization, and Risk Management 

5.1 HSI Requirements 

This section references HSI requirements and standards applicable to the P/P and identifies the 
authority that invokes them — e.g., the NASA Procedural Requirements document(s) that invoke 
applicability . 

HSI Requirements 

Key points: 

• Describe how HSI requirements that are invoked on the program/project contribute to 
mission success, affordability, operational effectiveness, and safety. 

• HSI should include requirements that influence the system design to moderate the work 
force (operators, maintainers, system administrative, and support personnel), required skill 
sets (occupational specialties with high aptitude or skill requirements), and training 
requirements. 

• Define the program-/project- specific HSI strategy derived from NASA-STD-3001 . Vol. 2, 
“NASA Space Flight Human System Standard, Volume 2: Human Factors, Habitability, and 
Environmental Health,” Standard 3.5 [V2 3005], “Human-Centered Design Process,” if 
applicable. 

• Capture the development process and rationale for any program-/ 
project-specific requirements not derived from existing NASA standards. In particular, 
work force, skill set, and training HSI requirements/goals may be so program-/project- 
specific as to not have NASA parent standards or requirements. 

• Identify functional connections between HSI measures of effectiveness used to verify 
requirements and key performance measures used throughout the life cycle as indicators of 
overall HSI effectiveness. 


5.2 HSI Organization, Roles, and Responsibilities 

In this section roles and responsibilities for P/P personnel assigned to facilitate and/or manage 
HSI tasks are defined — e.g., the HSI Practitioner [and/or Team if required by NPR 8705.2B, 
Human-Rating Requirements for Space Systems w/change 4 dated 8/21/2012 ]. HSI 
Practitioner/Team functional responsibilities to the program are described in addition to 
identification of organizational elements with HSI responsibilities. Describe the relationships 
between HSI Practitioner/T earn, stakeholders, engineering technical teams, and governing 
bodies ( control boards ). 
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5.2.1 HSI Organization 

• Describe the HSI management structure for the P/P and identify its leaders and 
membership. 

• Reference the organizational structure of the program (including industry partners) and 
describe the roles and responsibilities of the HSI Practitioner/ 

Team within that structure. Describe the HSI responsible party ’s relationship to other 
teams, including those for SE, logistics, risk management, test and evaluation, and 
requirements verification. 

• Provide the relationship of responsible HSI personnel to NASA Technical Authorities 
(Engineering, Safety, and Health/Medical). 

• Identify whether the P/P requires NASA- ( government ) and/or Contractor-issued HSI 
Plans, and identify the responsible author(s). Describe how NASA ’s HSI personnel will 
monitor and assess contractor HSI activities. For Contractor-issued HSI Plans, identify 
requirements and processes for NASA oversight and evaluation of HSI efforts by 
subcontractors. 

5.2.2 HSI Roles & Responsibilities 

• Describe the HSI responsible personnel ’s functional responsibilities to the P/P, 
addressing (as examples ) the following: 

• developing HSI program documentation; 

• validating human performance requirements; 

• conducting HSI analyses; 

• designing human machine interfaces to provide the level of human performance required 
for operations, maintenance, and support, including conduct of training; and 

• describing the role of HSI experts in documenting and reporting the results from tests 
and evcduations. 

• Define how collaboration will be performed within the HSI team, across P/P integrated 
product teams, and with the P/P manager and systems engineer. 

• Define how the HSI Plan and the SEMP will be kept aligned with each other. 

• Define responsibility for maintaining and updating the HSI Plan through the P/P ’s life 
cycle. 
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5.3 HSI Issue and Risk Processing 

This section describes any HSI-unique processes for identifying and mitigating human system 
risks. HSI risks should be processed in the same manner and system as other P/P risks 
( technical , programmatic, schedule). However, human system risks may only be recognized by 
HSI domain and integration experts. Therefore, it may be important to document any unique 
procedures by which the P/P HSI Practitioner/Team identifies, validates, prioritizes, and tracks 
the status of HSI-specific risks through the P/P risk management system. Management of HSI 
risks may be deemed the responsibility of the P/P’s HSI Practitioner/Team in coordination with 
overall P/P risk management. 

• Ensure that potential cost, schedule, risk, and trade-off concerns with the integration of 
human elements (operators, maintainers, ground controllers, etc.) with the total system 
are identified and mitigated. 

• Ensure that safety, health, or survivability concerns that arise as the system design and 
implementation emerge are identified, tracked, and managed. 

• Identify and describe any risks created by limitations on the overall P/P HSI effort ( time, 
funding, insufficient availability of information, availability of expertise, etc.). 

• Describe any unique attributes of the process by which the HSI Practitioner/Team 
elevates HSI risks to P/P risks. 

• Describe any HSI-unique aspects of how human system risk mitigation strategies are 
deemed effective. 

6.0 HSI Implementation 

6.1 HSI Implementation Summary 

This section summarizes the HSI implementation approach by P/P phase. This section shows 
how an HSI strategy for the particular P/P is planned to be tactically enabled — i.e., 
establishment of HSI priorities; description of specific activities, tools, and products planned to 
ensure HSI objectives are met; application of technology in the achievement of HSI objectives; 
and an HSI risk processing strategy that identifies and mitigates technical and schedule 
concerns when they first arise. 
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HSI Implementation 

Key points: 

• Relate HSI strategic objectives to the technical approaches planned for accomplishing 
these objectives. 

• Overlay HSI milestones — e.g., requirements definition, verification, known trade 
studies, etc. — on the program/project schedule and highlight any inconsistencies, 
conflicts, or other expected schedule challenges. 

• Describe how critical HSI key decision points will be dealt with as the program/project 
progresses through its life cycle. Indicate the plan to trace HSI key performance 
measures through the life cycle — i.e., from requirements to human/system functional 
performance allocations, through design, test, and operational readiness assessment. 

• Identify HSI-unique systems engineering processes — e.g., verification using human- 
in-the-loop evaluations — that may require special coordination with program/project 
processes. 

• As the system emerges, indicate plans to identify HSI lessons learned from the 
application of HSI on the program/project. 

• Include a high-level summary of the resources required. 


6.2 HSI Activities and Products 

In this section, map activities, resources, and products associated with planned HSI technical 
implementation to each system engineering phase of the P/P. Consideration might be given to 
mapping the needs and products of each HSI domain by P/P phase. Examples of HSI activities 
include analyses, mockup/prototype human-in-the-loop (HITL) evaluations, 
simulation/modeling, participation in design and design reviews, formative evaluations, 
technical interchanges, and trade studies. Examples of HSI resources include acquisition of 
unique/specific HSI skill sets and domain expertise, facilities, equipment, test articles, specific 
time allocations, etc. 

When activities, products, or risks are tied to life cycle reviews, they should include a description 
of the HSI entrance and exit criteria to clearly define the boundaries of each phase, as well as 
resource limitations that may be associated with each activity or product (time, funding, data 
availability, etc.). A high-level, summary example listing of HSI activities, products and known 
risk mitigations by life cycle phase is provided in Table A- 1: 
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Table A-1 HSI Activity, Product, or Risk Mitigation by Program/Project Phase 


Life Cycle 
Phase 

Phase Description 

Activity, Product, or Risk Mitigation 

Pre-Phase 

A 

Concept Studies 

• ConOps (Preliminary — to include training, maintenance, 
logistics, etc.) 

Phase A 

Concept & 

Technology 

Development 

• HSI Plan (Baseline) 

• ConOps (Initial) 

• HSI responsible party(ies) and/or Team identified before 
SRR 

• Develop mockup(s) for HSI evaluations 

• Crew Workload Evaluation Plan 

• Function allocation, crew task lists 

• Validation of ConOps (planning) 

Phase B 

Preliminary Design & 

Technology 

Completion 

• HSI Plan (update) 

• ConOps (Baseline) 

• Develop engineering-level mockup(s) for HSI evaluations 

• Define crew environmental and crew health support needs 
(e.g., aircraft flight decks, human space flight missions) 

• Assess operator interfaces through task analyses (for, e.g., 
aircraft cockpit operations, air traffic management, spacecraft 
environments, mission control for human space flight 
missions) 

• HITL usability plan 

• Human-Rating report for PDR 

Phase C 

Final Design & 
Fabrication 

• HSI Plan (update) 

• First Article HSI Tests 

• Human-Rating report for CDR 

Phase D 

System Assembly, 
Integ. & Test, Launch 
& Checkout 

• Human-Rating report for ORR 

• Validation of human-centered design activities 

• Validation of ConOps 

Phase E 

Operations & 
Sustainment 

• Monitoring of human-centered design performance 

Phase F 

Closeout 

• Lessons Learned report 
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6.3 HSI Plan Update 

The HSI Plan should be updated throughout the P/P ’s life cycle management and SE processes 
at key milestones. Milestones recommended for HSI Plan updates are listed in NPR 7 123. IB, 
Appendix G. 


HSI Plan Updates 

Key points to be addressed in each update: 

• Identify the current program/project phase, the publication date of the last iteration 
of the HSI Plan, and the HSI Plan version number. Update the HSI Plan revision 
history. 

• Describe the HSI entrance criteria for the current phase and describe any 
unfinished work prior to the current phase. 

• Describe the HSI exit criteria for the current program/project phase and the work 
that must be accomplished to successfully complete the current program/project 
phase. 
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APPENDIX B SAMPLE HSI IMPLEMENTATION PLANNING CHECKLIST 


Human Systems Integration (HSI) requires planning across a wide range of human concerns, 
incorporation of lessons learned, and collaboration with subject matter experts (SMEs). 

Typically an HSI practitioner is responsible for planning the effort and arranging for 
collaboration and organization of an HSI Team, as required. This sample checklist is provided 
as a work aid for the practitioner to help expand the range of considerations. The checklist is 
organized by HSI domain topics. Caveat: This list is not intended to be comprehensive and the 
author cannot anticipate the particular specialties, environment, and human interactions of all P/P 
efforts. 

B.1 Human Factors Engineering Analysis 

• Does the concept design being discussed present any significant challenges, implications 
or constraints in the following areas: 

Work/living space (especially number/size of berthing spaces) 

System or display integration 
Operability /Maintainability 
Anthropometry /Ergonomics 
Automation 
Ambient environment 

• Does the concept design require a new system interface or modification to an existing 
interface? 

• Does the concept design require new forms of collaboration between humans and/or 
across systems? 

• Are there new lighting conditions? 

• Is there special gear required that may impact task performance? 

• Are there personnel issues that may impact the system interface (Anthropometry)? 

• Will new technology impact the interface (Automation, Aiding)? 

• Does the concept design require the performance of additional tasks? 

• Are there specific performance thresholds and objectives that impact mission outcome? 

• Are there time limitations for task accomplishment? 

• Are there accuracy requirements for task accomplishment? 

• What are the physical constraints and workload placed on the crewmember by the 
system? 
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• What are the cognitive constraints and workload placed on the crewmember by the 
system? 

• What is the system’s ability to minimize the effect of environmental stressors on the 
crewmember? 

• What is the system’s ability to minimize the effect of mechanical (system-produced) 
stressors on the crewmember? 

• What is the system’s compatibility with crew life support and continuous operations? 

B.2 Operations Resources Analysis 

• Is there a legacy system to use as a personnel baseline? 

• Do the personnel levels need to be constrained to the same level as the predecessor 
system? 

• Will the personnel mix (crew, civilian, contractors) change significantly? 

• Is there a mandate to optimize or reduce personnel resources? 

• Have personnel resources been justified and/or modified to meet mission needs? How 
much could personnel grow before it would impact the life cycle cost (LCC) decision? 

• If the personnel estimate is greater than resources, what is the resource sponsor’s position 
regarding funding? 

• Is there a need for increased experience? 

• Is there a desire and/or need for unique combinations of skill sets, knowledge bases, and 
abilities? 

• Are the skill sets, knowledge base, and abilities required by the new capability projected 
to be available in sufficient numbers in the timeframe required? 

• Are there any known or projected changes to gender mix and/or cognitive abilities, 
physical characteristics, psychomotor skills, and/or experience level? 

• Does the concept design take into account the projected personnel pool? 

B.3 Maintainability and Supportability Analysis 

• Approximately how many resources will it take to operate, maintain, train and support 
the full capability? (Full capability includes all operational and maintenance [local and 
remote] components.) 

• What personnel estimate was used for the LCC assessment? 

• How does the personnel estimate compare to current requirements? 

• Will significantly new skill sets, knowledge bases, and abilities be required to support the 
capability? 


B-2 


HSI Practitioner's Guide 


• Have maintenance interval goals been identified? Have these been compared to 
reliability estimates to identify possible areas of risk? 


B.4 Habitability and Environment Analysis 

Acoustical Energy 

• What are the noise levels for the system? Can they be reduced? What are the concerns 
for potential fielding location? 

• Does this system meet the standards for steady state noise under the most severe 
operational and maintenance scenarios? 

• Does this system meet the standards for impulse noise under the most severe operational 
and maintenance scenarios? 

• Does this system meet the standards for blast overpressure under the most severe 
operational and maintenance scenarios? 

Biological Substances 

• Does the system configuration preclude exposure to microorganisms, their toxins and 
enzymes? 

Chemical Substances 

• Does this system produce or release any toxic substance during maintenance and 
operation? 

• Are personnel exposed to unacceptable levels of toxic vapors, gases, or fumes? 

• Are there any unacceptable levels of toxic gases in the crew environment when the 
vehicle is operating? 

• Has each chemical or toxic material used in or with the system been identified in the 
health hazard assessment report? 

• Does a hazard from exposure to exist? 

Radiation Energy 

• Are there hazards or potential hazardous exposures from ionizing radiation sources 
during operation, training, and maintenance? 

• Are there hazards or potential hazardous exposures from non-ionizing sources during 
operation, training, and maintenance? 

• Does the system contain any lasers detrimental to health? 

• Has the system been evaluated for potential radiation health hazards? 
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Physical Forces 

• Will this system produce any physical hazards? 

• Is adequate protection provided to preclude trauma to the eyes or body surface during 
system operation or maintenance? 

• Does the system meet vibration and shock requirements under all operational conditions? 

Survivability 

• Will the proposed capability increase the number/type (especially civilians and/or 
contractors) of individuals placed in harm’s way? 

• Does the concept design change egress systems requirements (if applicable)? 

• Does the Concept of Operations (ConOps) for the proposed capability increase the need 
for improved personnel survivability features? 

Temperature Extremes 

• Does the system provide adequate heating, cooling, and ventilation under routine, severe, 
and emergency conditions? 

Medical 

• Have health problems identified with legacy/reference systems and components been 
addressed and abated in this system? 

• What are disposal requirements? Will this process generate waste with special 
handling/disposal requirements? 

• If Waste cannot be eliminated, then there will be additional training requirements for use, 
handling, storage and disposal. 

• Does the system exhibit unacceptable conditions that might affect human performance 
capabilities (i.e., vision, olfaction, taste, hearing, reaction time, motor skills, strength, and 
cognitive skills)? 

• Have required health services (i.e., nutrition, water, sleep, exercise, medical care 
[preventive, diagnostic, treatment]) been identified where applicable? 

• Were required living conditions (i.e., personal hygiene, body waste management, crew 
quarters, mess, exercise area, recreation, trash, stowage, etc.) identified where applicable? 
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B.5 Safety Analysis 

• Has a safety risk assessment been completed? 

• Have safety risks concerning power sources been considered? 

Electrical 

Mechanical 

Hydraulics/pneumatics 

Chemical/explosive/propellants 

• Look for safety risks associated with: 

Exposed, moving equipment 

Hazardous materials or by-products 
High temperature devices 
Vehicular movement/flight 

• Ensure design requirement statements have been developed to address/prevent the impact 
of: 

Catastrophic loss of system or crew due to failure/malfunction of component or 
procedural error/omission 

Operational loss of system or disabling injury due to failure/malfunction of 
component or procedural error/omission 

Loss of system effectiveness or injury due to failure/malfunction of component or 
procedural error/omission 

• Are all trade-offs or impact issues looked at for their effects on all other HSI domain as 
well as system cost and performance requirements (e.g., excessive training and personnel 
capability requirements to compensate for system design weaknesses)? 

• Are all functional, cost and performance data, as well as assumptions and other criteria, 
consistent with other analyses being performed on the system? 

• Is the system safe for the crew/ground personnel to operate, maintain, repair, and 
support? 
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B.6 Training Analysis 

• Was any part of the planned system functionality related to addressing human 
performance or training deficiencies? 

• Could temporary or interim training be implemented to improve mission performance 
with current systems until the proposed concept design can be developed and deployed? 

• Will deployment of the new capability change crew planning and decision-making? 

• Will changes in either individual or team training be required to address the change to 
crew planning and decision-making? 

• Has the crew been tested for preliminary workload estimates in visual, auditory, motor, 
and cognitive capacity? Do they meet requirements? 

• If there is a desire and/or need for unique combinations of skill sets, knowledge bases, 
and abilities, are associated new training requirements feasible and reasonable? 

• Will there be sufficient time to adjust and implement required changes to training? 

• Have total system operational performance, support, or LCC objectives and thresholds 
been defined? 

• Will the concept design change who is to conduct the training (Government, Contractor)? 

• Will the concept design change where the training is conducted (Contractor Facilities, 
NASA Centers)? 

• Will the concept design impact the timing of the training (Duration, Availability)? 

• Does this affect cost estimates and LCC assessments? 

• Will the concept design change the method of training used (classroom, computer-based, 
on-the job)? 
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APPENDIX C HSI IMPLEMENTATION EXPERIENCES 


C.1 F-22 Hypoxia-Like Incidents: HSI Experience 

Introduction and Summary: 

The U.S. Air Force (USAF) F-22 program has experienced a number of operational incidents in 
which pilots experienced hypoxia-like symptoms during flight, with related symptoms post- 
flight. The USAF Scientific Advisory Board conducted an investigation and reported its findings 
in February 2012. The NASA Engineering and Safety Center (NESC) was then tasked to 
provide an independent analysis, and those findings were reported in August 2012. The 
following materials have been extracted from these reports and from NESC testimony given at a 
U.S. House Subcommittee hearing on this topic in September 2012. 

It is clear from the investigative findings that human-systems integration (HSI) is a key technical 
area that was insufficiently performed during F-22 system development, resulting in the 
operational incidents reported by the flight crewmembers. The F-22 contractor-provided aircraft, 
the government-provided flight crew equipment, and the human pilot form a complex system 
that must operate in an integrated manner during flight. Emergent properties of the integrated 
system were found to be inadequate for proper support of critical aspects of human health and 
performance. 

Sources: 

United States Air Force Scientific Advisory Board Report on Aircraft Oxygen Generation, SAB- 
TR-11-04, 1 February 2012 (Approved for Public Release) 

F-22 Fife Support System (ESS) Independent Analysis, NASA Engineering and Safety Center, 
NESC-RP- 12-00792, Version 1.1, August 23, 2012 (redacted FOIA release, 1 February 2013). 

F-22 Pilot Physiological Issues, Hearing Before The Subcommittee On Tactical Air And Fand 
Forces Of The Committee On Armed Services, House Of Representative, One Hundred Twelfth 
Congress, Second Session, Hearing Held, September 13, 2012, U.S. Government Printing Office, 
76-215 PDF, Washington : 2012, [H.A.S.C. No. 112-154] (publicly available). 

Scientific Advisory Board Report, Synopsis of HSI Experience: 

Background: 

The F-22 was developed during a period of major changes in the Air Force acquisition process. 
The majority of the Department of Defense military specifications and standards were rescinded 
and the acquisition workforce was reduced in favor of increased industry responsibility. A 
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refined program management structure delegated many decisions to Integrated Product Teams 
(IPTs) for non safety-critical functions. These changes left major uncertainties as to what was an 
“inherently governmental responsibility.” Additionally, the program underwent several major 
restructures driven by cost and funding constraints, to include major reductions in the size of the 
F-22 program office. 

During the early Advanced Tactical Fighter (ATF) development program, the precursor of the F- 
22 development, HSI analysts were chartered to focus on Manpower, Personnel, Training, and 
Safety. From 1989 to 1994, analysts from the Aeronautical Systems Division (ASD) HSI Office 
were collocated in the ATF Program Office. As a consequence of a heightened awareness of the 
manpower, usability, maintainability, safety, human effectiveness, and cost savings achievable 
by the application of human factor engineering methods, the analysts and program leadership 
were able to bring about changes representing different priorities and policies in program 
management decision-making. Engineering, human factors, manpower, personnel, training, and 
logistics were integrated. 

Technical support of the efforts beyond the HSI technical capabilities embedded within the ATF 
Program Office came from the Air Force laboratories and the ASD engineering offices in areas 
including: crew systems, life support systems, oxygen generation, propulsion, workload 
management, training methods and simulators, cockpit controls and displays, and human factors 
engineering. As a result of the ATF contract efforts, the F-22 pilot was given advanced personal 
protective equipment; integrated sensors, controls and displays; stealth technology; and sustained 
supersonic cruise. 

As the ATF moved beyond the fly-off phase and into the F-22 Engineering & Manufacturing and 
Development (EMD) phase, the acquisition policies had changed, diminishing the influence of 
proven military standards as well as national and international standards. Additionally, the 
workforce was downsized in response to acquisition reform initiatives. During the early 1990s, 
the ASD HSI Office work force was reduced to 21 positions. In 1994, prior to the 
developmental flight tests of the F-22, the HSI program office was disbanded due to funding and 
personnel reductions within ASD. The expertise required to perform the critical integration 
analyses became insufficient. Further, as a cost savings decision in the 2001 timeframe, the F-22 
program chose to terminate a contractor-developed life support ensemble in favor of the 
government-developed life support equipment developed as a part of the “Combat Edge” 
ensemble. In view of the fact that the Combat Edge ensemble had been certified, specialized, 
and tested end-to-end, testing of that equipment for the F-22 was not deemed necessary. 

The assessment by the Scientific Advisory Board, as documented in its report of February 2012, 
identified major shortfalls in the application of HSI principles, availability of appropriate 
breathing standards, and a comprehensive understanding of the aviation physiology implications 
of sustained operations at high altitude without a full pressure suit. The assessment of the 
environmental control system (ECS) and life support system development programs indicated a 


C-2 


HSI Practitioner's Guide 


major shortfall in the modeling and simulation of the system to determine performance under 
degraded conditions or in the presence of contaminants in the breathing gas. 

Report findings included: 

1. The F-22 on-board oxygen generating systems (OBOGS), Back-up Oxygen System 
(BOS), and Emergency Oxygen System (EOS) were not classified as “Safety Critical 
Items.” 

The Life Support System (LSS) IPT eliminated the BOS to save weight. 

The ECS IPT designed an Air Cycle Machine bypass to provide bleed air to the 
OBOGS in the event of an ECS shutdown. 

The EOS was deemed to be an adequate BOS. 

The ECS IPT decided to forgo the Air Cycle Machine bypass. 

With an ECS shutdown, the pilot’s flow of breathing air is cut-off thus requiring the 
pilot to activate the EOS to restore the flow of breathable air. 

Interrelated and interdependent decisions were made without adequate cross-IPT 
coordination. 

2. Over the past 20 years, the capabilities and expertise of the USAF to perform the critical 
function of HSI have become insufficient, leading to: 

The atrophy of policies/standards and research and development expertise with 
respect to the integrity of the LSS, altitude physiology, and aviation occupational 
health and safety. 

Inadequate research, knowledge, and experience for the unique operating 
environment of the F-22, including routine operations above 50,000 feet. 

Limited understanding of the aviation physiology implications of accepting a 
maximum 93-94% oxygen level instead of the 99+% previously required. 

Specified multi-national air standards, but deleted the BOS and did not integrate an 
automated EOS activation system. 

Diminution of Air Force Materiel Command (AFMC) and Air Force Research 
Laboratory (AFRL) core competencies due to de-emphasis and reduced workforce to 
near zero in some domains. 
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3. Modeling, simulation, and integrated hardware-in- the-loop testing to support the 
development of the F-22 LSS and thermal management system were insufficient to 
provide an “end-to-end” assessment of the range of conditions likely to be experienced 
by the F-22. 

Engine-to-mask modeling and simulation was non-existent. 

Dynamic response testing across the full range of simulated environments was not 
performed. 

Statistical analysis for analyzing and predicting system performance/risk was not 
accomplished. 

Performance of OBOGS when presented with the full range of contaminants in the 
ECS air was not evaluated. 

4. The F-22 life support system lacks an automatically-activated supply of breathable air. 

ECS shutdowns are more frequent than expected and result in OBOGS shutdown and 
cessation of breathing air to the pilot. 

The F-22 is the only OBOGS -equipped aircraft without either a BOS or a plenum. 

The “OBOGS Fail” light on the integrated caution, advisory, and warning system 
(ICAWS) has a 12-second delay for low oxygen, providing inadequate warning. 

When coupled with a rapid depressurization at the F-22’s operational altitudes, the 
“Time of Useful Consciousness” can be extremely limited. 

The EOS can be difficult to activate, provides inadequate feedback when successfully 
activated, and has limited oxygen duration. 

5. Contaminants identified in the ongoing Molecular Characterization effort have been 
consistently measured in the breathing air, but at levels far below those known to cause 
health risks or impaired performance. 

Contaminants that are constituents of ambient air — petroleum, oils and lubricants, and 
polyalphaolefin — are found throughout the LSS in ground and flight tests. 

OBOGS was designed to be presented with breathable air and not to serve as a filter. 
OBOGS can filter some contaminants and there is evidence it may concentrate others. 
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6. The OBOGS was developed as a “fly-to-warn/fail” system with no requirement for initial 
or periodic end-to-end certification of the breathing air, or periodic maintenance and 
inspection of key components. 

Engine bleed air certified “breathable” during system development. 

OBOGS units are certified at the factory. 

No integrated system certification. 

No recurring Built-In Test, inspections, or servicing. 

7. Given the F-22’s unique operational envelope, there is insufficient feedback to the pilot 
about the partial pressure of oxygen (PPO 2 ) in the breathing air. 

Single oxygen sensor well upstream of the mask. 

12-second delay in activating the ICAWS when low PPO 2 is detected. 

Inadequate indication of EOS activation when selected. 

No indication of pilot oxygen saturation throughout the F-22 flight envelope. 

8. The F-22 has no mechanism for preventing the loss of the aircraft should a pilot become 
temporarily impaired due to hypoxia- like symptoms or other incapacitating events. 

Disorientation, task saturation, and/or partial impairment from hypoxia could result in 
loss of the aircraft and possibly the pilot. 

9. The F-22 case study illustrates the importance of identifying, developing, and 
maintaining critical institutional core competencies. 

Over the last two decades, the Air Force substantially diminished its application of 
systems engineering (SE) and reduced its acquisition core competencies (e.g., SE, 
HSI, aviation physiology, cost estimation, contracting, and program and configuration 
management) to comply with directed reductions in the acquisition work force. 

By 2009, the Air Force had recognized this challenge and developed a comprehensive 
Acquisition Improvement Plan (AIP) and an HSI plan. 

Although the AIP has been implemented, the HSI plan is early in its implementation. 
A clear definition of “inherent government roles and responsibilities” is not apparent. 
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Respiratory Symptoms: 

The Study Panel heard anecdotal reports that F-22 pilots frequently experience respiratory 
complaints within minutes to hours after completion of a sortie. The complaints were dominated 
by the occurrence of a mild to moderate non-productive cough unaccompanied by fever or other 
systemic symptoms. The Study Panel heard preliminary results of a formal survey of the F-22 
and F-16 pilot community in which 65% of F-22 pilot respondents reported the occurrence of a 
cough during or shortly after some sorties, compared to 16% of F-16 pilot respondents. In 
addition, a significant number of F-22 pilots reported symptoms consistent with chest tightness. 
The temporal pattern of these respiratory symptoms does not appear to be consistent with 
acceleration atelectasis, a well-described entity in aviation medicine that is typically associated 
with the rapid onset of short-lived cough, chest tightness, or dyspnea. 

Consequently, a formal clinical and epidemiological investigation of the respiratory complaints 
was recommended. Irritant effects of ozone, volatile organic compounds, and inorganic gases 
and fine particulates have been associated with dry cough and chest tightness. Immunological 
responses, including antigen induced asthma or hypersensitivity pneumonitis, may also be 
associated with symptoms of this nature. 

Recommendations included: 

Re-energize the emphasis on HSI throughout a weapon system’s life cycle, with much greater 
emphasis during Pre-Milestone A and during Engineering and Manufacturing Development 
phases. 

• Identify and reestablish the appropriate core competencies. 

• Develop the capability to research manned high altitude flight environments and 
equipment, develop appropriate standards, oversee contractor development, and 
independently certify critical, safety-of-flight elements. 

Outcome: 

The assessment led the Scientific Advisory Board (SAB) Study Panel to make Findings and 
Recommendations to both mitigate identified risks in allowing the F-22 to return to flight and to 
provide the data necessary to identify the root cause(s) of these hypoxia-like incidents. 

The SAB recommendations led to the NESC report, with relevant HSI results synopsized below. 
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NASA Engineering and Safety Center Report, Synopsis of HSI Experience: 

The USAF and its contractors conducted investigations and a 4-month F-22 stand-down, without 
coming to a clear resolution of the issue. In May 2012, the USAF requested NASA assistance in 
the effort to determine the cause(s) of the hypoxia-like symptoms experienced by some F-22 
pilots. NASA was requested to review the post- incident protocols and recommend enhanced 
procedures with a greater emphasis on analysis of the entire life support and cabin pressurization 
systems, and to review the investigative process, ongoing root cause analysis, and the F-22 LSS 
as a whole to determine potential vulnerabilities to the pilot. 

The NESC led the effort with a team that included NASA flight surgeons, human factors experts, 
an Environmental Protection Agency (EPA) forensic chemist, an industry OBOGS expert, and 
NASA LSS engineers. The NESC team concurred that there was not a single root cause for the 
incidents, but a complex interaction of a number of factors, primarily: 

1. High concentrations of oxygen (O 2 ) at lower altitudes can lead to absorption atelectasis. 

2. The inevitable acceleration, which compounds the efforts of high O 2 . 

3. Restricted breathing due to the inappropriate inflation of the upper pressure garment 
(UPG) that not only prevented any relief of this atelectasis, but worsened the problem by 
causing rapid shallow breathing, and contributing to a reduction in cardiac output. 

4. Contributions of uncharacterized F-22 LSS vulnerabilities, such as pressure drops across 
components in the cockpit. 

The team found a number of issues with the systems providing support to the pilot. The LSS, 
ECS, and a govemment-fumished Combat Edge Aircrew Flight Equipment (AFE) are often 
treated as separate systems and controlled at the interfaces. The events experienced, however, 
are due to the complex interactions of these systems and the pilot. For example, pressure drops 
causing resistance to pilot breathing can be found across the interface between the LSS and the 
AFE and in the AFE components themselves. The unintended inflation of the UPG also restricts 
breathing. While the systems have no filter per se, the OBOGS and coalescer socks are filtering 
out contaminants. The OBOGS O 2 schedule is, on occasion, providing too much O 2 , which 
exacerbates the situation. Contamination as a cause has been ruled out by the USAF. 

The F-22 can be viewed as a system with many subsystems and components, each with varying 
degrees of direct and indirect influence on the sortie and on other components. In fact, it is a 
“system of systems.” The flight system can be viewed within the conceptual framework 
described by Technology-Human-Environment (THE) Model (Mauro, et al., in press). Adverse 
events during a flight can thus be seen as resulting from the interactions between the technology 
(i.e., hardware and software), the human, and the operational environment, within the context of 
the mission. There are two-way, three-way, and four-way interactions that should all be 
considered in any attempt to understand flight-related events. Given the dynamic nature of the 
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flight as a whole, and the complex nature of the human and the environment, the flight itself 
could be described as a complex system. 

There are several aspects of complex systems that seem particularly relevant to the physiological 
events experienced by some F-22 pilots: 

• Complex systems are very sensitive to initial conditions; small variations in initial 
conditions can produce large variations in outcomes. 

• Complex systems experience emergent phenomena, which cannot be predicted from the 
individual components (“the macro is different from the micro “the whole is greater 
than the sum of its parts ”). 

The human is a complex system and as such, it is often difficult to predict how humans will 
respond to novel environments. For instance, NASA flight surgeons cannot predict which 
astronauts will develop space adaptation sickness. Similarly, the sleep pattern a given astronaut 
will develop in space cannot be predicted. Like space flight, flying the F-22 involves a novel 
environment that is different from the human body’s natural environment. 

Viewing the F-22 as a complex system allows the interpretation of many of the attributes of the 
physiological events as the results of complexity. Together, the model and the notion of 
complexity could provide some insight not only into understanding the events themselves, but 
also into understanding the limitations of the investigative approach taken in pursuit of root 
causes. 

The F-22 physiologic events result from hypoxia. However, this is not the simple “hypoxic 
hypoxia” resulting from insufficient O 2 in the breathing air. It is far more complicated than that, 
and some basic understanding of aerospace physiology is necessary in order to properly 
understand the events. The F-22 pilot is exposed to a complex set of physiological interactions 
that on any day may combine to result in the cerebral cortex of the brain not receiving an 
adequate concentration of O 2 . A particular pilot may compensate adequately on a particular day, 
whereas the various factors combine to produce overt symptoms in another pilot on another day. 

Normally, in the lung, the blood flowing through the capillaries surrounding the alveoli (i.e., 
microscopic air sacks) is fairly evenly distributed throughout, such that almost all blood flowing 
past the alveoli is appropriately ventilated with air that carries an adequate amount of O 2 . 
However, when a person is sitting or standing upright, the force of gravity will pull some of the 
blood to the bottom portions of the lung, much like water will seep to the bottom part of a sponge 
left sitting on a table. In the case of the lung, the combined weight of the blood, the upper 
portions of the lung, and the chest wall causes the small air sacs at the base of the lung to 
collapse. This is called atelectasis and, in normal circumstances, is only a very small part of the 
overall lung volume. Also, the blood flowing past these collapsed alveoli is not absorbing any 
O 2 . The result of such blood flow is called “shunt.” On the other hand, the alveoli at the very 
top part of the lung have plenty of air being ventilated through them, but they have limited blood 
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flow; this is termed “dead-space” ventilation. Again, in normal individuals under normal 
circumstances, this accounts for a very small part of the overall ventilation of the lung. 

If the inspired air has a high amount of O 2 in it (e.g., 60 percent or higher), it can cause the 
nitrogen to wash out of the alveolus, thus effectively absorbing most (if not all) of the gas in that 
alveolus. This will lead to collapse of the alveoli, and is kn own as “absorption atelectasis.” This 
phenomenon is worsened if the small airways leading to the alveoli are pinched off due to the 
weight of the blood and lung tissue, resulting in the trapped O 2 in the alveoli being completely 
absorbed by the blood. Absorption atelectasis can occur in conjunction with acceleration 
atelectasis (see below) if the inspired concentration of O 2 is high (>60 percent), in the context of 
pulling G’s. Thus, too much inspired O 2 , in the fighter environment, can ironically cause 
hypoxia. 

One of the best ways of clearing areas of atelectasis in the lung is by taking in deep breaths, and 
by coughing. However, numerous observations have shown that this mechanism of clearing 
atelectasis in the F-22 community was inhibited because the UPG was inflating inappropriately. 
The result was that the inflated UPG could restrict the pilot’s chest wall movement, thereby 
keeping the pilot from being able to take in a full deep breath. Without being able to take deep 
breaths, it is also more difficult to cough adequately. Therefore, the chest wall restriction 
resulting from inappropriate UPG inflation inhibited effective reversal (clearance) of the 
atelectasis in the F-22 pilots. 

The results of the NESC study were briefed to a U.S. House Subcommittee as synopsized below. 

Extract from NESC/C. Cragg Testimony to House Subcommittee: 

The NESC assembled a team that included two NASA flight surgeons, two NASA human factor 
experts, an EPA forensic chemist, an industry oxygen generator system expert, and several 
specialized NASA LSS engineers. 

In the course of this investigation, the team reviewed data from multiple sources, visited 
manufacturing sites and F-22 bases and held numerous discussions with knowledgeable 
personnel. The NESC team's findings and recommendations are based on this data and not on an 
exhaustive review of all F-22 documentation. 

The NESC team concurs with the Air Force that the F-22 incidents can be attributed to several 
factors: 1) the high concentrations of oxygen at lower altitudes; 2) the inevitable acceleration 
which compounds the effects of high oxygen; 3) restricted breathing due to the inappropriate 
inflation of the upper pressure garment; and 4) contribution of uncharacterized F-22 life support 
system vulnerabilities, such as pressure drops [across] components in the cockpit. 


C-9 


HSI Practitioner's Guide 


The NESC team found a number of issues with the systems providing breathing air to the pilot. 
These systems are often treated as separate, but the events experienced are a result of the 
complex interactions of these systems, which, with the pilot included, are even more complex. 
Each flight puts extreme physiological demands on the pilot. The F-22 pilot community has 
come to consider a number of physiological phenomenon (sic) as a normal part of flying the 
Raptor, such as the difficulty in breathing and the Raptor cough. Acceptance of these 
phenomena as normal could be seen as a normalization of deviance. 

The NESC team found no evidence of a contaminant producing a toxic exposure. However, in 
any jet fighter environment, irritant compounds can be present. The F-22 has no effective 
filtration of breathing air or cabin air, which means irritant compounds could potentially enter 
the cockpit. 
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C.2 Shuttle Ground Processing: HSI Experience 

The Space Shuttle was “sold” to the American people and to Congress as a cost-effective way to 
get to/from low earth orbit (LEO). One of the primary selling points was that the Space Shuttle 
fleet could attain a launch rate of 40 round trips per year. This would provide remarkable and 
unheard of access to LEO. This rate would require that the ground processing turnaround time 
be on the order of 5 weeks for a fleet of 3 vehicles. The gap between the concept of operations 
(ConOps) for ground processing and the actual ground processing of the Orbiter is shown with 
remarkable clarity in Figure C.2-1, Shuttle Ground Processing: Conceptual vs. Actual. 



Source: Bo Bejmuk, Space Shuttle Integration (Lessons Learned Presentation) 

Figure C.2-1 Shuttle Ground Processing: Conceptual vs. Actual 


The concept for ground processing was not unlike that of a jet aircraft. But the actual facility 
required extensive scaffolding to protect the delicate systems and wiring, thermal tile system, 
and several other systems that required special care and attention while allowing close proximity 
to the vehicle for the large numbers of workers needed for Space Shuttle Orbiter refurbishment. 
The problems with the Shuttle Development were classic: 

• Insufficient definition of operational requirements during development phase 

• Concentration on performance requirements but not on operational considerations 

• Shuttle design organizations were not responsible for operational cost 

• Very few incentives for development contractors to address maintainability or turnaround 
time. 

Results: 


A very labor intensive (high operational cost) vehicle was developed and put into operations. 
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The Lessons Learned: 


• Must have the ConOps defined and applicable to all aspects of a system’s life cycle (e.g., 
maintenance and ground turnaround as well as on-orbit operations). 

• Levy the requirement on contractors to support the ConOps. 

• Must have continuity and integration between designers, ground operations, and flight 
operations requirements during the development phase. 
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C.3 F-1 19 Engine: HSI Experience 

Summary 

The ATF program was created in 1981 to create a military jet that would guarantee air 
superiority. Two contractor teams competed for the fighter contract. In 1991, the ATF contract 
was awarded to the Lockheed team’s F-22, powered by Pratt & Whitney’s F-1 19 engine. This 
award was based in part on the fact that the F-22’s engines offered superior reliability and 
maintainability. (Cost Estimation of HSI, Kevin Liu, 2010) 

This came about because the USAF placed an emphasis on reliability and maintainability from 
the beginning of the ATF program, considering that over 50 percent of the USAF budget was 
devoted to logistics and predicted to worsen. Pratt & Whitney chose to emphasize designing for 
the maintainer throughout all aspects of the program and conducted -200 trade studies as 
contracted deliverables. They also conducted thousands of information trades for internal use. 

As a result, the F-1 19 engine could be maintained with only 5 hand tools and all line replaceable 
units (LRUs) were “one-deep,” i.e., replaceable without removal of any other component. 
Furthermore, the LRUs could be removed with a single tool within a 20-minute window, even 
while wearing hazardous environment protective clothing. 

Additional Detail 

This HSI positive outcome case studies actions leading to the selection of Pratt & Whitney‘s F- 
119 engine for the Lockheed F-22 Raptor aircraft. Although this 1980-90s example pre-dates 
formation of the Air Force HSI Office at the Pentagon and subsequent formalization of HSI 
implementation, this well-documented example has served as a best practice case study for 
Department of Defense (DoD) HSI. (For additional information see “Cost Estimation of Human 
Systems Integration,” Kevin K. Liu, Masters of Science thesis at Massachusetts Institute of 
Technology [MIT], June, 2010). 

Overview : In November 1981, the ATF program was created to design a military jet able to 
guarantee air superiority against the Soviet Union. In 1983, a Lockheed/Boeing/General 
Dynamics team contracted into competition with Northrop Grumman. In 1991, the ATF contract 
was awarded to the Lockheed team’s F-22, powered by Pratt & Whitney‘s F-1 19 engine (see 
Figure C.3- 1). An important consideration in the contract’s award was that the F-1 19/F-22 
demonstrated superior supportability and maintainability. 



Figure C.3-1 F-1 19 Engine Cutaway (Pratt and Whitney, 2002) 
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Context : When the F-22 program was approved in 1981, the Air Force placed an early emphasis 
on supportability and maintainability and maintained this emphasis throughout the program’s life 
cycle. In June 1983, the Army, Navy, and Air Force signed a joint agreement to emphasize to 
the defense contractor communities the critical importance of improving operational readiness 
and supportability. At that time, system logistics costs were over 50% of the total Air Force 
budget and rising. The two prime competitors for the F-22 contract — Lockheed with Pratt & 
Whitney as their engine developer, and Northrop Grumman with General Electric (GE) as their 
engine developer — were first notified of the DoD’s sustainability concerns. 

The customer identified a priority on HSI in their requirements : In 1984, to address the growing 
escalation of systems logistics expenditures, the Air Force created a Reliability, Maintainability 
& Sustainability (RM&S) program. Besides reducing life cycle cost (LCC), the RM&S program 
sought to address reliability and durability problems that had plagued engines powering the 
existing Air Force’s F-15 Eagle. Developed in the 1970s, the F-15 was specifically designed to 
counter the Russian MiG-25, with requirements emphasis placed on performance not RM&S. 

Unfortunately, the high performance of the F-15 engine meant that it was more prone to failure 
and downtime. By the 1980s, the Russian air superiority threat was no longer as pressing, the 
growth in logistics costs was deemed unsustainable, and supportability began to be emphasized 
over performance. As a result, the Air Force wanted improved RM&S not only on the engine for 
the F-22, but on the system as a whole. Specific supportability goals for the F-22 were defined 
by the RM&S program and announced to the prime contractors. These included reducing the 
parts count, eliminating maintenance nuisances such as safety wire, reducing special-use tools, 
using common fasteners, improving durability, improving diagnostics, etc. 

Understanding customer needs : Pratt & Whitney decided to center its competitive strategy on 
RM&S superiority, understanding the customer had made RM&S critical to the competition. For 
the F- 119 engine, Pratt & Whitney decided not only to meet the Air Force‘s RM&S 
requirements, but to emphasize designing for the maintainer throughout all aspects of the 
program. The company’s approach exemplified the best practices of what is now known as HSI. 

Pratt & Whitney conducted approximately 200 trade studies using evaluation criteria such as 
user safety; supportability; reliability; maintainability; operability; stability; and manpower, 
personnel, and training. Figures of merit were developed for the trades to determine which 
human-centered disciplines should participate in each trade study. Pratt & Whitney also brought 
their engineers to Air Force maintenance facilities so that the engine designers could experience 
first-hand the challenges created for maintainers by past designs. Maintainers showed how tools 
were poorly designed, manuals had unclear instructions, and jobs supposedly meant for one 
person took two or more to complete safely. Fessons learned were passed on to every engineer 
on the F-l 19 engine design team and ground rules for maintenance design were established. 
Integrated Product Development (IPD) teams were established so that multiple, diverse 
discipline experts worked side-by-side on the design. Design changes were approved by a 
Configuration Control Board (CCB) of senior engineers from multiple technical disciplines. 
Design review processes ensured the work of one group did not create unforeseen problems for 
another. Proactive leadership made certain that HSI principles were followed. 


C-14 


HSI Practitioner's Guide 


One of the most important requirements for the F-l 19 was that only five hand tools be needed to 
service the entire engine. (In the end, the F-l 19 engine required five two-sided hand tools and 
one other, for 1 1 tools total.) Other requirements included: all LRUs were to be serviceable 
without removal of any other LRU, and each LRU was removable within 20 minutes. 
Subassembly drawings required annotation with the tools needed for service. Maintenance must 
be possible while wearing hazardous environment clothing. Maintenance tasks must 
accommodate maintainers in the 5 th percentile female to the 95 th percentile male range. Built-in 
test diagnostics were to eliminate the need for special engine diagnostic equipment. Training 
was computer-based. 

To verify the maintainability of their design, Pratt & Whitney developed several full-scale mock- 
ups of the F-l 19. Though requiring a significant investment this ability to intimately evaluate 
the human/system interaction with maintainers allowed engineers to confirm their designs 
achieved maintainability goals. 

HSI efforts contribute to competition success : In 1991, both Pratt & Whitney and GE were 
awarded contracts worth $290 million to build prototype engines for flight evaluation. GE chose 
to emphasize the flight performance of its F-l 20 engine over RM&S, though the F-l 20 did meet 
the Air Force‘s RM&S requirements. Despite the F-120‘s superior performance in the air and 
higher thrust-to-weight ratio, on April 23, 1991, the Air Force chose the combination of Pratt & 
Whitney’s F-119 and Fockheed’s YF-22 to be developed into the F-22. Pratt & Whitney had 
demonstrated a better understanding of the Air Force’s RM&S needs, having invested more time 
and money into HSI demonstration than had GE. Pratt & Whitney had presented a management 
plan and development schedule that the Air Force considered sensitive to their needs. On August 
2, 1991, contracts worth $11 billion were awarded to Fockheed and Pratt & Whitney 
demonstrating the Air Force’s strategic investment in and commitment to HSI. 

Key HSI success factors : The actions of both the Air Force and Pratt & Whitney were examples 
of top-level leaderships’ role to sound HSI and SE practices. From a SE standpoint, the Air 
Force set formal requirements and expected product trade studies based on HSI concerns. At the 
program’s outset Air Force leadership set clear supportability goals, explained their intent, and 
funded programs to show prime contract engineers actual Air Force maintenance conditions. 

Pratt & Whitney embraced processes that supported sound HSI outcomes and included diverse 
disciplines in major design and configuration decisions. Pratt & Whitney leadership invested in 
mock-ups, conducted testing, and held engineers accountable for RM&S standards, all of which 
led to HSI success. These combined efforts of customer and contractor to define clear 
requirements and communicate common expectations led to success. 

The efforts described above can be summarized into several key HSI success factors: 

1. Air Force policy to elevate HSI early in acquisition and development. 

2. Design and trade studies that included HSI domains and cross-domain integration. 

3. HSI’s early inclusion in the contractor’s SE methodology. 

4. Participation with Air Force maintainers to understand their practices and challenges. 
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Insights into HSI’s success in this case study: 

1. The Air Force put their desired outcome into practice via formal HSI deliverables and 
requirements. 

2. The IPD teams engaged HSI domain expertise in system design and the CCBs ensured 
multi-disciplinary management oversight. (IPD teams are more recently referred to as 
IPTs, now a hallmark of sound SE practice.) 

3. Pratt & Whitney’s early commitment to embrace HSI in their SE and project 
management practices defined the system from concept through flight test. 
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C.4 Constellation Program: HSI Experience 

Following text adapted from: “Human Systems Integration (HSI) Case Studies from the NASA 
Constellation Program, ” S. Baggerman, D. Berdich, M. Whitmore (Human Systems Integration 
2009 ). 

There was no NASA agency-wide or even center-based deployment of the term HSI, or an 
associated definition. However, the inclusion of the human as part of overall system 
performance was not only recognized, but supported by the agency. 

The NPR 8705. 2B, Human-Rating Requirements for Space Systems (w/change 4 dated 
8/21/2012) contained a set of technical requirements that establish a benchmark of capabilities 
for human-rated space systems. 

The CxP 70024E, Constellation Program Human-Systems Integration Requirements document 
was developed specifically for the Constellation Program (CxP) from NASA Standard 3000, or 
NASA’s Man-Systems Integration Standard, and provided a key mechanism for Constellation to 
achieve NASA’s agency-level human-rating requirements. 

Human systems integrators at the Johnson Space Center (JSC) and other centers across the 
agency were involved not only with the allocation and interpretation of the HSIR and with the 
human rating certification process, but also with the processes associated with human centered 
design and HSI. They worked with SME to ferret out cross-cutting issues that could affect the 
crew. 

HSI worked with vehicle and habitat designers who ensured that HSI issues were included in 
trade studies and analyses to determine how best to balance vehicle and mission design while 
meeting the needs of the crew and considering human health and performance limitations. They 
used HSI tools and practices to mitigate the risks to mission and crew and to optimize vehicle 
design. 

Work began to standardize the processes, tools, and techniques used to support HSI, as well as 
developing a definition or culture aimed at formalizing the term HSI and its practice as a NASA 
discipline. HSI had an evolving definition steered through benchmarking outside of NASA, also 
rooted in NASA’s history, and due in great part to the emerging needs of current programs and 
projects. 

HSI practitioners were heavily involved in the Constellation Program and Projects on many 
levels. The Crew Exploration Vehicle (CEV) Project also formally recognized a NASA HSI 
lead who integrated human health and performance concerns by leading or participating in 
integration forums to coordinate related technical issues with implementers, stakeholders, and 
subject matter experts in order to characterize risks and potential or realized system impacts, and 
to provide review of developing designs and architectures. 

Within the Constellation Program’s System Engineering and Integration (SE&I) Office, a 
Human Systems Integration Group (HSIG) was established with responsibility and authority, and 
accountability equal to other discipline area Systems Integration Groups (SIGs). The HSIG led 
human system integration across Projects for both hardware and software for all Constellation 
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crewed space systems, including the operability and usability of interfaces and hardware and 
software requiring human/operator interactions by the flight crew during ground and flight 
operations, as well as ensuring cross-systems, cross-mission support of human health and 
performance, including crew habitability accommodation and human interfaces. The HSIG also 
acted as the book manager of HSIR. 

A Human Systems Integration Technical Forum was established with the HSIG to provide 
interpretation of HSI requirements and verifications methods. 

Much work still lay ahead to standardize HSI processes, as well as products or required 
deliverables, which are less reactionary and more proactive in terms of Program and Project 
Management, and are more systematic. 

NASA human systems integrators made much progress within the Constellation Program and 
Projects to mitigate risks to mission and crew, and to promulgate consideration of human health 
and performance in design and throughout the system life cycle, especially in light of a lack of 
formal recognition of the discipline area or a widely accepted definition of HSI. There were 
multiple agency-level documents that required human health and performance to be considered 
in spacecraft and mission design, enabling human systems integrators to contribute to the CxP. 
Most HSI efforts were at the grass roots, or bottom-up level, however, and were successful due 
to the nature of the integrators and subject matter experts themselves as much as due to the 
practices they used. 

Following text adapted from: “Human Systems Integration (HSI) In Practice: Constellation 
(CxP) Lessons Learned, ” (2011) J. Rochlis Zumbado 

Human concerns are currently integrated into NASA Development programs primarily through 
Requirements and Verification. 

NASA agency-level document drivers: 

• NPR 7120.5E - Space Flight Program and Project Management Requirements 

• NPR 7 123. IB - NASA Systems Engineering Processes and Requirements 


HSI domains are not covered in a single requirements document, and in some cases, they are not 
covered at all: 

• Based on the design reference mission (DRM), program- specific requirements are 
developed from the standards and invoked by the Human Rating NPR 8705. 2B. 

• NPR 8705. 2B: 2.3.8 Human-System Integration Team. In 2011, no other Agency NPR 
calls for “HSI.” To date, this NPR has only been applied to CxP, and there were lessons 
learned and best practices revealed. 
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HSIG was a part of Integrated Systems Performance under the SE&I Director for CxP: 

• Co-Led by JSC Engineering and (now) Human Health & Performance Directorate 

• HSIG managed the HSIR and was responsible for the human systems content in the 
Human Rating Certification Package. 

• Performed horizontal technical integration of human systems concerns across the projects 

• Resolution of human system technical issues used a community of practice (CoP) 
influence model. 

• Consisted of Subject Matter Experts (SMEs) and representatives from all stakeholder 
organizations 

• CoP method was a success story in terms of bottoms-up technical integration, but not 
without its limitations. 

The CoP Model Facilitating Technical Issue Resolution: 

• The CoP was used to facilitate resolution of technical issues. 

• Program to Project teaming and coordination led to better vertical integration. 

• Consolidation of technical positions was enabled at the discipline level and provided 
decision boards with integrated assessments. 

• Collaboration of SMEs from across Agency, industry, and academia helped to: 

Find the best expertise, regardless of location, and helped educate the community as 
to who the experts are and where they reside 

Bring to bear the full breadth of this expertise within the technical disciplines to solve 
complicated issues 

Disseminate expert knowledge and actually advanced the volume of knowledge in 
particular disciplines 

• However, there were issues with a CoP implementation of HSI: 

Decisional authority resided above the CoP, which made design decisions difficult to 
drive from the CoP level. 

No single Technical Authority owned or represented HSI. 

Authority intended for Human Systems Integration Team (HSIT) was not realized 
within the CoP model. 

Human systems concerns often confused with JSC Astronaut Office input. 

• CoP Lessons Learned & Best Practices: 

CoPs were effective at resolving technical integration issues. 
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Participation in the CoP across all levels is necessary. 

Management must engage the CoPs directly when solving problems and seek CoP 
input when making decisions. 

Organizational structure, and previously mentioned responsibility and authority issues 
are a factor here. 

Roles, Responsibilities & Decision Making in Projects & Programs: Lessons Learned & Best 
Practices: 

• Organization should be established very early in the life cycle with clear definitions of 
Roles, Responsibilities, Accountability and Authority (RRAA). 

HSI team should be among the functions represented within the program structure. 

• Provide the Authority to match the Accountability. 

• Architect the decision making process. 

Provides clarity and supports RRAA’s between Program & Projects 

• Ensure board representation is knowledgeable and empowered to act on behalf of those 
they represent. 

Seek the input of the appropriate integration groups. 

• Drive down decision making to the lowest level as long as potential system to system 
impacts have been considered and cleared. To do this, check: 

Who is Responsible? 

Who is Accountable? 

Who needs to be Coordinated with? 

Who needs to be Informed? 

After CxP, NASA is changing the way it does business: 

• Suggest moving from a standards-to-requirements approach, to process driven: 

Provide guidance on what to do, how to do it, and by which milestones. 

Prescribe less and advise more. 

• Promote cross-directorate interaction in support of establishing an HSI vision, 
methodology, and implementation plan. 

• Address the lack of formal structures that promote cross -directorate diversity of ideas. 
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To Achieve the HSI Vision at NASA: 

• Commitment from Agency level of the importance of HSI and its role in project design, 
development and operation 

• Development of HSI processes, practices and tools that can be implemented on projects 
of varying scales, as well as commercial ventures 

• Ownership of HSI activities, from development of an HSI plan through to design and 
operations, along with the appropriate authority and management responsibility 

• Not just about adding HSI integrators to projects, the goal is to have Project Managers 
thinking like HSI integrators 


Following text adapted from: “VSM Activity Debrief: Constellation Program Lessons 
Learned, ” M. Whitmore, L. Pickett, J. Adolf, G. Vos (2011). 

CxP Human Factors team captured lessons learned (successes and challenges) related to HSI 
processes and requirements associated with the CxP. 

Key items that were done well: 

• HSI disciplines were represented by project system managers in Orion. 

• Did not stove-pipe within the supporting directorate - we effectively integrated our 
expertise within multiple engineering groups. 

• Obtained good visibility in CxP projects. Joined the project teams and worked with them 
in design. Not equal engagement in each project, but well engaged across CxP. 

• Having clear requirements got HSI at the table when projects were being created, and 
opened the door for HSI. 

• An HSI scorecard was a very useful tool. Even though it was not a formal project 
deliverable, it was effective at tracking and obtaining integration with various project 
systems. 

• Several HSIR requirements were significantly challenged in the beginning, but were 
effectively addressed and refined as CxP progressed. 

• Process documents created to provide prime contractors with test and evaluation 
methodologies were very useful. 

• Task analysis (TA) worked very well and proved itself as a valuable and effective 
planning and Test and Evaluation (T&E) tool. Phase based TA worked well to 
understand the vehicle with SMEs, and developed useful information for system 
maturation. 
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Core opportunities for improvement: 

• An executive-level HSIT as required by NPR 8705. 2B was never created, and the cross 
collaboration amongst existing forums and working groups lacked a single point of 
approval/rejection for HSI issues of consideration. 

• Roles and responsibilities (R&R), including programmatic guidance, should be formally 
established as soon as possible, and not allowed to remain ambiguous. Issues related to 
R&R pervaded both project working groups as well as internal Human Health and 
Performance Directorate interactions. A hierarchical command structure with checks and 
balances should be considered. 

• Program and project constraints drove multiple technical review issues associated with 
resource allocation, limitations on resolution of review comments, and limited time for 
effective document and design review. Programs should ensure they provide adequate 
time for technical milestone reviews. 

• Programs such as CxP have a significant and unaddressed need for pre-acquisition work 
so that HSI deliverables are included. CEV Project had planned such a deliverable, but it 
was removed by the project, an action that critically limited HSI authority. 

• HSI requirements should focus on performance criteria, and avoid design specification. 

• Several HSIR verification requirements exceeded their parent HSIR requirements. 


Actionable Recommendations Executable within Human Health and Performance Directorate: 

• Generate an implementation plan of how HSI operates and integrates with projects and 
programs. The plan should be mapped to NPR 7 123. IB milestones and criteria. 

• Roles and responsibilities (R&R), including programmatic guidance, should be formally 
established as soon as possible, and not allowed to remain ambiguous. A hierarchical 
command structure with checks and balances should be considered. 

• HSI requirements should focus on performance criteria, and avoid design specification. 
Simplify requirements to the extent possible and allow Subject Matter Experts (SMEs) to 
provide design and development guidance when needed. 

• When working with design groups, focus on what is needed so that projects can 
understand and support the requirement. 

• Some HSIR requirements need revision/maturation (e.g., suited anthropometry, strength, 
response time). Consider a requirements review to identify requirements/verifications 
needing further work. 

Often verification requirements need more refinement than parent requirements. 
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Some verifications have potential scoping issues, which need to be addressed. The 
verifications in some cases need to be scoped to an achievable process allowing 
verification in an affordable way. 

Some verifications exceeded their parent requirements. 

• Need a focused group to ensure early HSI engagement both on pre-acquisition work on 
projects and associated integration efforts. 

• All requirements are not equal in importance, but HSIR is structured and presents them 
that way. Need an indented structure to indicate priority for requirements. 

• Utilize lessons learned in risk identification, benefit/cost analysis, and asking 
management to make decisions based upon inclusion of all factors and options. 


Actionable Recommendations Executable with Community Support: 

• A full HSIT with tech representation per NPR 8705. 2B is needed, with the top level 
HSIT existing irrespective of any specific project and program. Program and project 
representatives to the HSIT would be appointed as new programs and projects are 
brought into existence. 

This relates to multiple CxP issues, including oversight of HSI requirement revisions, 
dispute resolution regarding requirement interpretations by projects, and 
determination of project specific tailoring or implementation letters. 

• Programs should ensure that prime contractors provide adequate time for technical 
reviews. 

• Programs such as CxP have a significant and unaddressed need for pre-acquisition work 
so that project deliverables are included to ensure HSI inclusion and integration. 

• Programs should be established before their child projects. 


Next Steps Near Term: 

• Establish an institutional HSIT at JSC or at a directorate level. 

• Initiate strategic work on Human Readiness Level/Human Rating Assessment tools, HSI 
roles in certification of flight readiness for human flight tests, etc. 


Forward Work Items: 

• Push for establishing an Agency level HSIT as required by NPR 8705. 2B. 

• Develop a formal lessons learned process to efficiently capture, disseminate, and utilize 
lessons learned for continuing work and future programs. 
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• Provide detailed interview / survey data to HSI implementation leads/managers. 

• Leverage these detailed lessons learned findings to improve HSIR. 

• Leverage these lessons learned to refine HSI interaction for continuing CxP projects. 

• Feed forward lessons learned into commercial HSI implementation and future programs. 

• Continue efforts to leverage DoD HSI best practices and implementation. 
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C.5 HSI Ideal State for Future Large Scale Human Space Flight Program 

An ideal future NASA implementation of HSI must fully embrace the key concepts noted in 
section 1.4 of this document. 

Following is a high-level overview of what an ideal NASA HSI process should entail: 

1) In conceiving new systems, missions, or technologies, ideas spring from recognizing the 
successes and limitations of prior operational accomplishments. NASA’s early human 
space flight program followed a logical sequence of operational demonstrations that 
ultimately led to sending three crewmembers to the moon and landing two of them on 
the surface. The DoD serves as a current example of continual operational assessment 
and process improvement. For the DoD, experience in the combat arena continually 
leads to experience-based conceptualization of new system designs or enhancements — 
i.e., “if only we could do <new idea>, we could be more successful when this situation 
arises.” In short, embrace the perspective that operational experience germinates new 
system concepts. Then the implementation and execution of HSI — i.e., the strategic 
mission of HSI — then becomes clearer: Ensure that the original operational vision is 
implemented. 

Section 4. 4. 1.2, Design Solution: Process Activities, of NASA/SP-2007-6105, Systems 
Engineering Handbook, discusses some of the challenges of maintaining a focus on the original 
vision for a new system: 

“Once it is understood what the system is to accomplish, it is possible to devise a variety of ways 
that those goals can be met. . .Ideally, as wide a range of plausible alternatives as is consistent 
with the design organization’s charter should be defined, keeping in mind the current stage in the 
process of successive refinement. When the bottom-up process is operating, a problem for the 
systems engineer is that the designers tend to become fond of the designs they create, so they 
lose their objectivity; the systems engineer often must stay an “outsider” so that there is more 
objectivity. This is particularly true in the assessment of the technological maturity of the 
subsystems and components required for implementation. There is a tendency on the part of 
technology developers and project management to overestimate the maturity and applicability of 
a technology that is required to implement a design. This is especially true of “heritage” 
equipment. The result is that critical aspects of systems engineering are often overlooked.” 

The HSI practitioner can provide ongoing program or project (P/P) objectivity through 
continually insisting on validating the question, “Are we building the system originally 
envisioned?” Why would HSI perform this role? An assessment of prior program cost- 
escalation and “mission creep” — i.e., a loss in focus from the original vision and mission — 
would likely indicate that it was often late consideration of the inter-relationship of 
hardware/software systems with P/P human elements that led to issues. See the examples in 
appendices C.2 on Space Shuttle and C.3 on the F-199 engine. 
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2) The NASA SE process outlined in NPR 7123.1 and NASA/SP-2007-6105 break the life 
cycle of a P/P into distinct phases. An overview of these phases can be found in section 
3.1, Engine Processes Overview, of this document. For successful implementation of 
HSI, it is essential that HSI engage from the earliest outset of a program or project — i.e., 
HSI is integral to Pre-Phase A, Concept Studies. At this earliest formalization of a P/P, 
the NASA SE process requires development of the ConOps — Concepts of operation and 
scenario development. The ConOps is a more detailed and documented vision of how 
the total system is to perform in the operational arena. The ConOps should address both 
nominal and off-nominal mission/system scenarios. 

Additional tools can and should be brought to bear to refine the ConOps, notably 
human/system task analyses, clear functional understanding and allocation of tasks the 
hardware and software are to perform vs. the tasks human 

operators/controller/maintainers are to perform (i.e., “function allocation” in brief), and 
clearly planned or envisioned allocation of roles and responsibilities among the human 
elements required to make the system operational. Note that all of these processes are 
mentioned in both NASA SE documentation and in the Human-Centered Design 
requirement in NASA-STD-3001, NASA Space Flight Human System Standard. In 
performing these early concept clarifying efforts, maintaining the focus on the human 
element is the critically unique attribute of HSI. In short, in Pre-Phase A, HSI must take 
the original operational vision for the system and codify it into formal P/P performance 
goals. The HSI practitioner should strive to establish goals — i.e., SE Key Performance 
Parameters (KPPs) — that can be objectively tracked through the rest of the system’s life 
cycle. Examples might be: size of the ground control contingency; reliance on 
autonomy vs. ground control; maintenance ConOps and repair strategy (e.g., tool set 
size, spares supply, manufacturing in place, skills required, training, etc.); 

3) In Phases A and B of the NASA SE process, the system design takes shape and trade 
studies are performed to select the final hardware/software design that will be built. Of 
course, every design decision has implications for the total system performance. 
Particularly for the HSI perspective, every hardware/software design decision has 
implications for human interaction with the system. During design, it is imperative that 
these impacts are continually assessed and evaluated against the original P/P goals for 
the human element. Are there impacts to safety? To mission effectiveness or 
efficiency? To the numbers and skills of personnel contingents required to make the 
system operational? To training? To the total population of personnel accommodated 
by the system? 

P/P HSI practitioners and implementers of the HSI Plan must continually press for an iterative 
approach to conceptual design and to prototype or model the system with the intent of 
performing human-in-the-loop (HITL) evaluations that ensure the HSI KPPs for total system 
performance are on track. The HSI KPPs themselves may be re-validated during system 
conceptualization and design and new KPPs may appear. This is one reason the P/P HSI Plan is 
intended to be a living document that is updated at major life cycle milestones. These processes 
remain consistent with currently NASA-documented SEg and human-centered design 
methodologies. 
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4) If appropriate and thorough HSI has been applied through Phase B of the life cycle, the 
remaining effort entails that the HSI practitioners track and verify the HSI goals through 
development and into the operational arena. 

Though several key document changes have been made in recent years to support 
implementation of this HSI process overview, there is still much work to be done. Examples of 
forward work include (but are not limited to): 

• There is no formal mandate in any NASA documentation that requires application of HSI 
to program or projects. 

• Much existing NASA human factors documentation focuses only on the human factors of 
flight crew interaction with flight systems, not the interactions of all personnel who 
interact with a system throughout its life cycle. 

• Much existing human factors and human-rating NASA documentation focuses on human 
space flight programs and projects but HSI is fully applicable to unmanned space flight 
and to aeronautics programs and projects. 

• There is considerable human factors engineering, habitability, and environmental factors 
NASA documentation but other aspects of HSI — e.g., maintenance, logistics, training — 
need to be as thoroughly addressed. 

• No NASA Headquarters level organization currently enforces the application of HSI, or 
holds responsibility for establishing a cohesive, consistent approach to Agency 
implementation of HSI. 

Another example of forward work for the HSI implementation is Model-Based System 
Engineering (MBSE). It is approached as a special topic in the 2015 update material to 
NASA/SP-2007-6105 that looks forward to a higher degree of formal rigor in system modeling 
and analysis, enabled through virtually integrated, comprehensive system models (rather than 
disconnected, partial models). It will also entail a model-centric versus document-centric 
method of system design and development. For the HSI team, MBSE will present a significant 
challenge, even beyond the challenge to SE in general, to develop and integrate human analytical 
models into the larger system model. The wide range of variability in human physiological 
function and behavioral performance and the extreme complexity of the interactions among 
many human physiological and cognitive functions may be very difficult to capture and to 
represent in models that can be connected (via automation) to other parts of a comprehensive 
system model. In an ideal-state P/P, the abstraction of key human characteristics may be a useful 
technique to generate HSI models that can become parts of an entire MBSE system model; 
however the SME expertise within all HSI domains will continue to be critical to inform the 
effective design of missions and systems that are compatible with human populations. 

Another example of the future ideal state of HSI practice is an expanded program of HSI training 
available for both the HSI Practitioner and for the P/P Manager. The NASA SE curriculum 
should be expanded to add these courses. 
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For the Practitioner (and HSI team members), the training should include a series of courses 
similar in concept to the Naval Post Graduate School’s HSI Certification Program. These could 
include the following topics: 

• COURSE 1: Introduction to Human Systems Integration. The policies that govern HSI, 
the domains that comprise HSI, and the capabilities and limitations of humans in complex 
systems under a variety of stressful conditions. 

• COURSE 2: Human Systems Integration in the Acquisition Lifecycle. How HSI 
practitioners work with developers, designers, program managers, logisticians, and 
engineers to influence the entire life cycle of a system - from concept development 
through the operations and support phase. 

• COURSE 3: Human Systems Integration Tools, Tradeoffs, and Processes. The theories 
and tools to help HSI practitioners to assist acquisition program leaders in making trade- 
off decisions in a resource-constrained environment. 

• COURSE 4: Human Systems Integration Case Studies and Applications. Application of 
material learned in the previous three courses to evaluate historical case studies and to 
engage in HSI activities in typical acquisition systems. 

For the P/P Manager, a condensed HSI course will be ideal, to provide this individual with a 
broad overview of HSI, its purpose, and specifically its value to the P/P in terms of outcomes 
(cost, performance, schedule). 

Some of the key aspects of an HSI ideal state are: 

• Institutional and Program Management Principles: 

Recognize the human elements of the mission-system as critical to success. 

Focus on early human integration to achieve a life cycle return on investment. 

Design to achieve best value from the humans who are critical to the mission. 

Balance human-system risks as major elements of all risk inherent to the program. 

Make decisions with a long-term view of all phases of development and operation. 

Leverage the Agency’s human research and technology foundation. 

• Program Culture: 

Value the distinct roles of all teams including HSI. 

Implement the Agency’s path for human space exploration. 

Enhance leverage of knowledge captured from past programs. 

• System Engineering: 

Apply appropriate rigor to manage technical baseline and all associated risk. 

Recognize Agency technical authorities’ roles in technical/human requirements. 

Conduct the SE Engine processes methodically to achieve program technical goals. 

Empower a formal HSI Team within SE to conduct HSI processes. 
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• HSI Involvement: 

Establish a firm basis of Agency infrastructure for application of HSI in programs. 
Apply the HSI key tenets within the SE Engine environment. 

Engage all essential HSI domains and subject matter expertise. 

Conduct a rigorous integration of human with system software/hardware elements. 
Implement risk balancing by meeting human health and performance standards. 


Institutional Investment 

When new NASA P/Ps are established and funded, full integration into P/P management and SE 
processes is the key to successful savings through HSI, including fulfdling HSI’s cost-savings 
potential. Optimal integration requires high-level coordination among domain owners, 
facilitated by HSI practitioners working within P/P system working groups (communities of 
practice) and IPTs to obtain optimum solutions. 

By working very diligently within P/P processes in a coordinated HSI framework arena, experts 
in human factors, crew systems, safety, and other relevant human-centered fields can better 
influence system designs to control human-related LCC growth, prevent the need for later 
hardware and software modifications for improved system operability and/or safety, and reduce 
late- stage discovery of HSI hazards due to lack of early human integration — the “fly and fix” or 
“test and fix” difficulties that have historically plagued the system acquisition process. 

Institutionally, having well established HSI practitioners can be invaluable to decision making 
bodies, boards, and non-advocate review panels. Support for “head-turning” decision-makers 
who can ask “What do you think?” and receive an experience-seasoned answer must be preceded 
by an intuitional investment and ingrained in the engineering culture. 

Taking the strategic view for human space flight in general, there are numerous future technical 
and human performance challenges to be faced in advancing NASA’s vision and mission. 
Agency institutional HSI organizations need to not only to work to meet current P/P needs, but 
also to develop the capabilities, skills, and infrastructures to prepare NASA to meet long- 
standing strategic challenges such as learning to optimize human effectiveness and the efficient 
deployment of human assets in the design of complex systems. For example, a future human 
space flight mission to Mars will undoubtedly require a significant number of human-system 
trade-offs, evaluations of new concepts and designs to autonomously support human crews, and 
plus innovation in human/technical solutions that has as of yet not occurred. Building expertise 
in managing these processes is an investment that must be in place long before a particular P/P is 
initiated. Finding ongoing funding to build and maintain an infrastructure for HSI outside of 
current P/P resources will be a formidable challenge. 
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HSI Institutional Challenge 

HSI challenges the traditional paradigm that a Program and Project budget can be separated 
between development and operational phases. 

If the budgets are separated, then the PM managing the development may not optimize 
operational cost since it is “someone else’s problem.” And the PM managing the operations 
will inherit a suboptimal design, destined for work-arounds and high staffing. 

The developing manager should be accountable to Life Cycle Cost containment and 
performance optimization across all phases. 
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C.6 Agile Development Brings New Challenges for Software Assurance at 
NASA 

Capability Maturity Model Integration, the NPR 7150.2B-required method for critical NASA 
Class A and Class B software projects, is used heavily for defense and aerospace projects as a 
rigorous process improvement model. Its best practices necessitate both documented processes 
and evidence that the processes are being followed. 

On the other hand, most “pure” agile development methods cycle through “sprints” — quick 
rounds of production followed by review. There is typically less documentation and the team 
learns as it goes. 

“It’s an ideal approach in private industry, where you want to be first to market. You get your 
product out there and then you release updates,” said NASA Software Assurance Technical 
Fellow Martha Wetherholt. “But when you’re heading for one launch of one vehicle, where 
safety needs to be proved and documented, a straight agile approach may not be the best option.” 

Wetherholt envisions NASA using an approach that combines elements of agile development 
with more traditional, plan-based development. Rigorous documentation is still necessary for 
NASA’s safety critical applications and functions. Software needs to be analyzed to see how it 
may be contributing to system hazards. Then, needed controls and mitigations need to be 
designed in and tested to make sure that the controls work as required. Also, software is often 
used to detect and mitigate hardware hazards; these software requirements and design changes 
also must be documented, designed in, and verified and validated to work. Software Assurance 
personnel need to provide evidence and proof that appropriate safety measures were taken. 

Despite its challenges, agile development brings creativity and opportunity to NASA’s next- 
generation missions. In addition, many of NASA’s commercial partners use or will use agile 
development in their projects. To provide effective oversight, Software Assurance personnel 
must continue to adapt, leam and keep up-to-date with the latest software development 
processes, and software developers need to embrace Software Assurance as part of the agile 
process. 

One such example is Marshall Space Flight Center’s (MSFC) Space Launch System (SLS) flight 
software team, which has been using tailored agile methods in combination with more traditional 
methods. 

Software Engineering Process Group Lead Helen Housch (Cepeda Systems & Software 
Analysis, Inc.) described a tailored process where portions of the development life cycle are 
performed within sprints (agile methods), while others — such as overall planning, black-box 
requirements development, and final product integration — are done outside of the sprints. 

The SLS team has had success with the agile development process, and has seen several 
improvements. Housch stated communication and coordination among requirements, 
design/implementation, and test teams have improved significantly, as teams work together to 
incrementally develop software and other work products. 
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The SLS flight software team’s Software Assurance personnel participate in sprint review 
meetings and are involved in the sprints as they elect. Communication with external 
stakeholders including Software Assurance and senior management has also improved, as 
incremental development progress is more quantifiable and evident through post-sprint review 
meetings. Housch agreed that Software Assurance participation in the sprint activities is 
beneficial to the process. 

“Incremental development allows the customer to see progress much earlier in the lifecycle,” 
said Housch. “The traditional software development methods do not always allow customer and 
manager visibility into the progress until the end of the implementation phase. With agile, 
stakeholders are able to see progress at regular intervals (every six months or so) as software is 
developed and planned functionality is released.” 

A customized agile approach allows flexibility to tailor the project’s processes to effectively and 
efficiently meet mission objectives. “No two organizations do agile exactly the same,” said 
Housch. “The agile approach should be tailored to the goals of the organization that’s performing 
the agile activities.” 
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Equipment, https://standards.nasa.gov/documents/viewdoc/33 14905/33 14905 

• NASA-STD-7009, Standard for Models and Simulations (2008). 
https ://standards .nasa. gov/documents/detail/33 15599 

• NASA-STD-8709.20, Management of Safety and Mission Assurance Technical 
Authority (SMA TA) Requirements. 

https://standards.nasa.gov/documents/viewdoc/3315772/3315772 

• SSP 50005, International Space Station Flight Crew Integration Standard (NASA-STD- 
3000/T). (SUPERSEDED by NASA-STD-3001 and NASA/SP-2010-3407). 

D.4 NASA Handbooks 

• NASA/SP-2007-6105 Rev 1, NASA Systems Engineering Handbook. 
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301.pdf 

• NASA/SP-2010-576, NASA Risk-Informed Decision Making Handbook. 
http://www.hq.nasa.gov/office/codeq/doctree/SP2010576.htm 

• NASA/SP-2010-3407 Rev 1, Human Integration Design Handbook (HIDH). 
http://ston.isc.nasa.gov/collections/TRS/listfiles.cgi?DQC=SP-2010-3407REVl 

• NASA/SP-2014-3705, NASA Space Flight Program and Project Management Handbook. 
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20150000400.pdf 

• NASA/TP-2014-218556, Human Integration Design Processes (HIDP). 
http://ston.isc.nasa.gov/collections/TRS/listfiles.cgi?DOC=TP-2Q14-2 18556 


D-3 


HSI Practitioner's Guide 


• NASA Cost Estimating Handbook. 
http://www.nasa.gov/offices/ooe/CAD/nasa-cost-estimating-handbook-ceh/ 

D.5 NASA Documents/Articles 

• Baggerman. Berdich, Whitmore. (2009) Human Systems Integration (HSI) Case Studies 
from the NASA Constellation Program. 

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20090001318.pdf 
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